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1.  Summary 

Advances  m  information  technology  have  resulted  in  better  ways  to  use  information  for  the 
management  of  business  activities.  The  integration  of  stand-alone  systems  combined  with  im¬ 
proved  information  recording,  organization  and  communication  offers  benefits  for  the  life- 
cycle  management  of  marine  structures.  The  future  offers  even  greater  rewards  as  research, 

development  and  introduction  of  new  technologies  and  organization  changes  are  utilized  to 
further  improve  marine  safety. 

This  report  provides  a  roadmap  for  the  commercial  development  of  modules  within  an  infor¬ 
mation  system  to  fecilitate  life-cycle  management.  This  includes  areas  fi-om  ship  design  and 
construction  as  well  as  operations  including  inspection,  maintenance  and  repair. 

Using  the  guidelines  developed  in  the  Marine  Structural  Integrity  Program  (MSIP)  Report 
Pea,  1992]  and  the  SSIIS  Phase  I  Report  [Schulte-Strathaus,  1994],  this  report  outlines  the 
development  of  an  information  system  for  the  life  cycle  management  of  ship  structures.  The 
functions  of  existing  ship  stnictural  management  appUcations,  including  both  computer  and 
manud  systems  have  been  integrated  into  the  prototype  description  of  the  Ship  Structural 
Integnty  Information  System  (SSIIS). 

The  role  of  Business  Process  Reengineering  in  the  management  of  information  is  discussed  as 
it  affects  the  desi^  of  modules  within  the  SSIIS  project.  The  reengineering  approach  to  busi¬ 
ness  process  design  obtains  maximum  advantage  fi-om  the  implementation  of  information 
technology.  The  development  of  Information  Systems,  fi-om  planning  and  analysis  to  design  is 
discussed  to  provide  a  fi-amework  for  the  development  of  the  SSIIS  prototype. 

The  development  of  a  SSIIS  prototype  provides  an  outline  of  the  basic  data  structure  for  the 
integration  and  development  of  a  marine  structural  information  system.  To  demonstrate  the 
advantages  of  such  a  system  the  development  of  the  prototype  has  focused  on  the  manage¬ 
ment  of  structiu-al  survey  and  inspection  information,  and  the  CAIP  report. 

^  infonmtion  system  must  focus  on  business  processes,  support  fimctions  and  activities  and 
te  enable  an  organization  to  make  accurate  decisions,  quickly  and  efSciently.  The  aim  of  the 
bbllb  project  IS  to  allow  all  stakeholders  in  maritime  safety  to  improve  the  quality  of  the  de¬ 
sign  and  operation  of  ship  structures  through  the  organization  of  information. 

It  should  be  realized  that  SSIIS  is  only  one  component  of  a  comprehensive  Ship  Quality  In¬ 
formation  System  (SQIS)  [Moore,  Bea,  1995].  Other  components  of  a  SQIS  address  the 
equipment,  hardware,  and  facilities  onboard  a  ship;  ship  operations  (cargo,  routing,  loading 

unloading,  supphes);  ship  personnel;  and  the  organizations  responsible  for  the  ship  and  its  op¬ 
erations. 

It  IS  through  a  SQIS  that  a  full-scope,  life-cycle  ship  information  and  communication  system 
can  be  realiz^.  A  SQIS,  and  the  business  reengineering  processes  that  provide  the  fi-ame¬ 
work  for  Its  definition  and  implementation,  can  lead  to  significant  reductions  in  work  and 
costs.  It  IS  only  when  such  reductions  in  work  and  costs  can  be  delivered  that  the  necessaiy 
resources  wiU  be  devoted  to  develop  and  implement  SSIIS,  and  ultimately,  SQIS 


2.  Introduction 


This  report  documents  the  second  phase  of  the  Ship  Structural  Integrity  Information  System 
(SSIIS)  project.  The  SSHS  project  was  sponsored  by  the  U  S.  Coast  Guard  Research  &  De¬ 
velopment  Center  through  the  National  Maritime  Enhancement  Institute  of  the  Maritime 
Admimstration  (MARAD).  The  project  was  initiated  by  the  Department  of  Naval  Architec¬ 
ture  &  Offshore  Engineering  at  the  University  of  California  at  Berkeley  in  September  1993. 

The  second  phase  of  the  SSHS  project  had  two  main  objectives: 

•  to  continue  development  and  documentation  of  standards  for  the  development  of  a 
computerized  Ship  Structural  Integrity  Information  System  for  tank  ships  through 
a  review  of  database  components  and  protocols. 

•  to  continue  demonstration  of  the  application  of  these  standards  with  a  prototype 
PC  based  system  SSHS  prototype  including  a  CAIP  reporting  module. 

The  SSIIS  project  had  its  beginnings  with  the  report  published  in  1992  by  the  Ship  Structure 
Committee  for  the  development  of  Marine  Structural  Integrity  Programs  (MSIP)  [Bea, 
1992].  The  procedures  were  designed  for  commercial  ships,  with  focus  given  to  oil  tankers 
Md  crude  oil  carriers.  The  MSIP  procedure  adopted  a  program  similar  to  the  Airframe 

Structural  Integrity  Program  (ASIP)  established  by  the  U.S.  Air  Force  and  the  Federal  Avia¬ 
tion  Agency. 

The  objective  of  an  MSIP  was  to  integrate  the  requirements  of  ship  owners  and  operators, 
builders  and  regulators  to  obtain  maximum  safety  and  economic  benefit.  The  keystone  of  the 
objectives  was  highlighted  to  be  an  information  system  which  revolves  around  the  life-cycle 
operation  of  marine  structures.  The  format  of  such  a  system  is  represented  in  Figure  2.1. 


Figure  2. 1  :  MSIP  -  Vessel  Information  Structure 


The  MSIP  study  outlined  the  infoimation  requirements  governing  the  life-cycle  operation  of 
tanker  vessels.  This  included  design,  construction  and  operational  information.  The  SSIIS 
project  uses  this  structure  as  a  starting  point  for  the  development  of  a  general  ship  informa¬ 
tion  ^stem.  The  MSIP  objectives  and  information  requirements  are  detailed  in  Chapter  3. 
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Chapter  3  also  provides  a  summary  of  the  foUowmg  backgroutrd  topics  as  deemed  relevant  to 
the  development  of  a  ship  information  system: 

.  The  first  phase  of  the  SSIIS  project,  which  encompassed  the  review  of 
management  of  inspection  information  and  the  CAIP  reportu^ 
the  description  of  trends  and  causes  firr  feilures  was 

in  several  of  the  CAIP  reports  reviewed.  One  of  the  objectira  of  the  SS  p  J 

devetopment  of  analytical  tools  to  fecilitate  the  documentanon  of  fadure  trends. 

•  The  NIDDESC/STEP  ship  product  model  description,  which  details  the  smndard  fi)r  the 
structur^descriptions.  This  has  ten  developed  P-"  “  ^ 
international  standard  and  hence  provides  a  starting  pomt  for  convertmg  between  non- 
grdphicdl  and  graphical  ship  model  information. 

.  A  review  of  an  onboard  vessel  maintenance  system,  tte 

onboard  ship  functions  and  activities.  This  system  was  developed  by  Stolt  Parcel  Mers 
and  handles^the  maintenance  of  mechanical  systems,  and  the  reqmsition  and  purchase  of 
both  spare  parts  and  general  ship  provisions. 

A  detailed  overview  of  Process  Innovation  or  Business  Process  Reengineering  is  ” 

Cl^  4  ^Engineering  is  the  complete  change  of  existing  business  processes  with  the  un- 

pleEntation  of  information  technology  and  oigantetiote  ^ 

methodology  behind  reengineering  and  emphasizes  the  objectives  of  the  SSIIS  p 
safety  and  ^ovide  economic  benefit  not  only  for  ship  owners  and  oj^rators  but  also  regula- 
torv  authorities  Reengineering  provides  a  framework  for  the  development  of  information 
^Sems  to  evolve  a  new,  more  efficient  way  of  working  rather  than  simply  automatmg  exist¬ 
ing  processes. 

The  concepts  of  Information  System  development  are  discussed  in  Chapter  5.  This  is  in¬ 
tended  to  provide  the  guidelines  and  theory  for  the  development  of  information  syst^. 
Topics  include  the  stages  of  information  system  development  and  associated  activities, 
includes  planning,  analysis,  design  and  construction  of  an  information  system.  The  techmques 
and  concepts  discussed  are  used  in  the  following  chapter. 

Chapter  6,  Structural  Information  System,  breaks  down  the  processes  involte  ^  tl*  ^ 
agement  of  ship  structure  into  functional  activkies.  These  fimctional  activities  ^  .^te 
teken  down  into  information  requirements  and  the  relationslups  between  activinM  de- 
scribed.  The  functional  activities  relate  only  to  the  management  of  ship  structures  and  t  e 
formation  requirements  that  match  the  MSIP  information  guidelines. 

The  SSIIS  database  prototype  is  outlined  in  Chapter  7,  this  system  was  developed  using  the 
Microsoft  database  application  ACCESS.  The  prototype  is  representative 
system  recommendations  for  the  life-cycle  management  of  ship  structures  and  thus  mcorpo- 
rates  the  reengineering  ideals.  The  prototype  reflects  ideas  generated  to  erjiance  safety  ^d 
not  just  a  system  to  automate  existing  ship  operation  functions.  Future  development  of  the 

SSIIS  project  is  detailed  in  Chapter  8. 

Chapter  9  provides  the  conclusions  to  Phase  II  of  the  SSIIS  project. 


3.  Background 

This  chapter  is  given  to  provide  a  background  to  previous  work  done  and  identify  other  re¬ 
search  pertinent  to  marine  structural  integrity. 

3.1.  Marine  Structural  Integrity  Programs 

The  Ship  Structure  Con^ttee  funded  a  study  to  establish  a  procedure  for  development  of 
Marine  Structural  Integrity  Programs  (MSIP)  for  commercial  ships,  with  particular  focus  on 
tankers,  [Bea,  1992].  The  aim  was  to  adopt  a  procedure  similar  to  the  Airframe  Structural 
Integrity  Program  (ASIP)  established  by  the  U.S.  Air  Force  and  the  Federal  Aviation  Agency. 

The  fundamental  objective  of  an  advanced  MSIP  is  to  improve  the  quality  of  ship  structural 
system  throu^out  the  life-cycle  of  the  structure,  from  design  to  construction  and  during  op¬ 
eration.  Quality  issues  related  to  a  ship  structure  system  include  serviceability-durability,  reli¬ 
ability  and  economy  (initial  and  long-term).  Quality  related  improvements  include  more  efiB- 
cient  inspection,  improved  economics  and  safer  operation  and  more  effective  maintenance. 

Maximum  benefit  for  the  marine  industry  will  be  obtained  only  if  the  MSIP  is  focused  on  the 
life  cycle  of  ship  structures.  Life-cycle  ship  structural  integrity  programs  must  be  initiated  at 
design  phase,  from  the  formulation  of  design  rules,  and  extended  throughout  the  construction 
and  operating  phases.  The  requirements  of  all  sectors  must  be  identified  and  trade-ofis 
made  to  obtain  compatible  life-cycle  orientated  assessment  criteria. 

The  MSIP  as  proposed  should  be  a  fizll-scope  ship  integrity  program  that  addresses: 

•  structural  systems  (integrity,  capacity  and  durability) 

•  equipment  systems  (navigation,  propulsion,  steering,  piping,  electrical) 

•  operations  systems  (vessel  traffic  control,  training,  licensing,  re-certification) 

As  identified  in  the  report  and  shown  below,  several  key  potential  organization  and  technical 
developments  need  to  be  introduced  as  part  of  an  advanced  MSIP: 

•  Centralized  archiving,  evaluation  and  dissemination  of  potentially  imnortant  in¬ 
formation  relating  to  MSIP. 

•  Training,  testing  and  verifying  the  capabilities  and  performance  of  design,  manu- 
frcturing,  operations  and  maintenance  personnel. 

•  Development  of  cooperative  and  intensely  communicative  associations  among  the 
major  sectors,  including  regulatory,  classification,  owner/operator,  and  production 
^d  maintenance  sectors  with  a  focus  on  safety  and  durability  issues,  avoiding 
hidden  agenda’  and  legal  impediments  to  communications. 

•  Development  and  application  of  advanced  technologies  with  heavy  emphasis  on 
testing  and  monitoring  founded  on  sophisticated  and  realistic  analysis. 

•  Development  and  application  of  a  comprehensive  approach  to  engineering  for, 
and  maintenance  of  structural  reliability. 
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•  Design  of  ship  structures  that  not  only  address  the  functional  and  ^rengt  - 
quireLnts,  but  also  design  for  constructabUity, 

with  heavy  emphasis  given  to  damage  tolerant  design  and  disability  desig 
minimize  the  risks  of  high  consequence  accidents  and  unexpected  mamtenance. 

The  MSIP  has  two  fundamental  objectives 


to  develop  a  desirable  level  of  structural  reliabiUty  (integrity,  durabiUty)  for  a 
newly  constructed  ship  structure,  and 


-  V 

•  to  maintain  an  acceptable  level  of  structural  reliability  throughout  the  ship’s  life. 

The  purpose  of  the  MSIP  is  to  identify  and  minimize  the  risks  of  low  ' 

quence  structural  Mures  while  maximizing  the  serviceabihty  and  duraMty  of  the  jhiP-  J 
most  significant  problems  associated  with  ship  structures  are  unexpected  and  often  the  result 

of  ignoring  required  mamtenance. 

It  has  been  identified  that  an  industry-wide  MSIP  project  must  address  the  technical  devel- 

opSnts  which  can  enable  ship  owners  and  t 

Jdety  and  economic  benefits  of  more  durabie  and  reliable  ship  structures.  MSIP  techmcal  de 

velopments  should  include: 


structural  design  plans  (addressing  the  life-cycle  phases,  design  criteria,  damage 
tolerance,  durability,  materials  and  operations) 


structural  analysis  guidelines  (addressing  loadings,  stren^h  design,  desi^  for  du¬ 
rability  and  damage  tolerance  and  design  for  inspectability,  constructabihty  and 

maintenance) 


•  requirements  for  the  testing  of  critical  components  to  demonstrate  capacity,  du¬ 
rability  and  damage  tolerance,  and  in-service  monitoring  to  provide  additional  m- 
formation  on  structure  loadings  and  performance. 

It  was  identified  in  the  MSIP  that  the  development  of  an  industry-wide  information  system 
for  archiving  design  and  construction  information,  operations  structural  trackmg  and  mam  e- 
nance  tracllig  was  required.  This  would  include  the  results  of  inspections,  hull  response 
monitoring,  maintenance  programs,  records,  repairs,  modifications,  jp 

ments  of  performance.  The  requirements  for  the  information  system  identified  m  the  MSIP 

project  are  shown  in  Table  3.1. 

The  information  requirements  identified  in  the  MSIP  project  form  the  basis  of  SSIIS.  Rather 
than  simply  automating  these  information  requirements,  the  SSIIS  project  exammes  processes 
associated  with  the  management  of  ship  structures  and  provides  the  stimulus  to  innovate 
these  processes  and  improve  the  quality  of  ship  structures  in  an  efficient  way. 

The  challenge  of  the  SSIIS  project  is  to  achieve  the  goals  established  by  the  MSIP  projert 
and  ensure  they  are  incorporated  into  the  information  system.  In  summary,  as  identified  the 
information  system  must  achieve  the  following  goals: 

•  be  life-cycle  focused,  and 

•  address  structural,  equipment  and  operations  systems 
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MSIP  1 

Flans  Module 

Operations  Module 

Design 

Voyages 

Construction 

Cargoes 

Operations 

Ballasting  Procedures 

Inspections,  Monitoring,  Maintenance,  Repairs 

Cargo  loading  and  unloading  procedures 

Cleaning 

Design  Module 

Monitoring  results 

Design  Criteria 

Accidents 

Rules 

Materials  and  Fabrication 

Maintenance  Module 

Cleaning 

Stress  Analysis 

Coating  Repairs 

Damage  Tolerance  Analysis 

Cracking  Repairs 

Durability  Analysis 

Steel  Renewals 

Design  Development  Test  Program 

Momtoring  Program  Develc^unent 

Inspection  and  Monitoring  Module 

Classificaticm  Program 

Corrosion  Survey  Reports 

Design  Documentation 

Cracking  Survey  Reports 

Design  Drawing 

Monitoring  Program  Reports 

Construction  Module 

Repair  Module 

Specifications 

Coating  Repair  and  Maintenance 

Builder 

Cathodic  Protection  Repairs  and  Maintenance 

Quality  Assurance  and  Control  Procedures 

Fracture  Repairs 

Quality  Assurance  and  Control  Reports 

Steel  Renewals 

Inspections 

Design  Variances 

As^built  Drawings 

Table  3.1  :  MSIP  information  requirements 
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3.2.  SSIISl 

The  first  phase  of  the  Ship  Structural  Integrity  Information  System  (SSIIS)  ad^essed  the  m- 
of  the  MSIP  tafbnnation  requ—  As  SS 

nroerams  used  to  record  ship  inspection  information  were  reviewed.  In  addition  the  Uit  ca 
^ea  Inspection  Plans  (CAIP)  of  six  vessels  were  examined  for  their  adherence  to  the  IT  . 
^ast  G^d  requirements.  Based  on  these  findings,  the  format  for  an  automated  system  was 

given. 

3.2.1.  Background  -  Vessel  Inspection  and  Reporting 

In  recent  vears  research  and  development  projects  have  focused  on  the  development  ^d 

toJSnen/ation’of  databa.  systems  to  store  manipula^  and 

eaSiered  during  the  operation  of  commercial  vessels.  Much  of  this  effort 

trated  on  oil  tankers  due  to  regulatory  requirements  and  specific  rtructural  configurations 

require  periodic  inspections  resulting  in  large  amounts  of  survey  data. 

Due  to  the  disproportionately  high  number  of  fatigue  cracks  found  in  vessels  operatmg  on  the 
Zta  PiS  Servi«  (TAPS)  trade  route,  the  U.S.  Coast  Guard  requues  a  Cnt.^ 

Area  Inspection  Plan  (CAIP)  for  these  vessels.  The  C^  for  ^  J 

methods  used  by  vessel  operators  for  the  documentatam  and  trackmg  of  structural  Mures 

[USCG,  1991] 

The  CAIP  report  contains  detailed  information  on  the  vessel’s  fi-acture  history,  corrosion 
lontroUyster^^  repairs.  In  addition  the  CAIP  requires  operators  to  document 

trends  inL  occurrence  of  fatigue  and  corrosion  incidents.  The  pl^  ^ eas'one  ITZ 

to  include  the  most  recent  survey  data  for  the  determination  of  the  cntical  areas.  One  ot  the 

objectives  of  the  SSIIS  project  is  address  the  requirements  of  the  CMP  report  and  to  eve  op 
methodologies  to  assist  operators  in  the  identification  of  failure  trends. 

These  requirements  have  resulted  in  a  large  amount  of  data  that  needs  to  be  managed.  This  k 
most  easUy  done  if  the  vessel  and  survey  information  is  contained  m  a  database.  In  ^^ition  t 
these  reg^tory  reporting  requirements,  information  systems  can  greatly  fecihtate  and  im¬ 
prove  the  quality  of  inspection,  maintenance  and  repair  operations. 

The  Mernalioml  Association  of  Classiflcalion  Societies  (lACS)  recMfy  publish^  a  of 
rules  governing  the  conduct  of  surveys  for  existing  vessels,  (Enhanced 
isline  Vessels)  RACS,  1993].  The  document  is  partly  based  on  recommendations  issued  by 
Iriiime  oUation  (IMO,  and  the  guitM.  mtmMs 
tions  published  by  the  Tanker  Structure  Cooperative  Forum,  [TSCF,  1 990] ,  [TS  , 

The  lACS  document  requires  shorter  inspection  intervals  for  uncoated  baU^t  ^ 

makes  it  the  owner/operator’s  responsibiUty  to  provide  detailed  information  related 
and  corrosion  survey  results,  including  trends  and  damage  statistics. 

3.2.2.  Existing  Database  Systems 

Partly  due  to  the  U.S.  Coast  Guard  requirement  of  the  implementation  and  f 

CritiMl  Area  Inspection  Plans  (CAIP),  and  also  to  facilitate  mspectioti,  mamtenance  and  re- 


pair  (IMR)  operations,  information  systems  have  been  developed  that  store  general  vessel 
information  in  conjunction  with  survey  data.  Several  of  these  systems  were  evaluated  in  order 
to  determine  the  general  approach,  the  information  contents  and  the  overall  effectiveness. 

Special  regard  was  given  to  the  method  used  to  determine  and  represent  failure  locations 
(cracks  and  corrosion)  within  a  vessel.  The  use  of  graphical  information  was  analyzed  to  de¬ 
termine  the  relation  between  the  cost  for  data  input  and  the  increase  in  information  contents 
and  overall  usability. 

Evaluated  systems  include  the  CATSIR  database  systems  (developed  by  Chevron  in  coopera¬ 
tion  with  Oceaneering),  ARCO's  HuU  Fracture  Database  (HFDB),  FracTrac  (developed  by 
MCA  Engineering),  SID  (Structural  Inspection  Database,  developed  by  MIL  Systems)  and 
the  Ship  Information  Management  System  (SIMS),  developed  as  part  of  the  Structural 
Maintenance  Project  for  New  &  Existing  Ships  (SMP)  project  conducted  at  the  Department 
of  Naval  Architecture  &  Ofishore  Engineering  at  UC  Berkeley. 

The  purpose  of  the  review  of  existing  database  systems  was  to  study  the  different  approaches 
taken  to  archive  and  use  ship  information  and  survey  results  and  to  document  the  applicabiUtv 
of  each  system  for  a  future  SSIIS. 

In  a  different  database  development,  a  selection  guide  for  tankers  of  10,000  deadweight  tons 
or  more  has  been  developed  and  is  updated  and  published  annually,  [Tanker  Advisory  Center, 
1994].  The  guide  is  intended  to  aide  tanker  charterers,  cargo  owners  and  others  involved  with 
tankers  in  the  selection  of  tankers  that  perform  satisfectorily  and  pose  a  minimal  risk  of 
casualties. 

A  rating  system  has  been  developed  that  assigns  a  rating  to  each  tanker  based  on  a  set  of  cri¬ 
teria,  i.e.  casualties,  age,  name  changes,  owner's  total  losses  and  oil  spills,  classification  soci¬ 
ety,  owner,  flag  of  registry,  etc.. 

Of  particular  importance  is  the  inclusion  of  casualties  and  oil  spills.  Any  future  tanker  data¬ 
base  development  has  to  evaluate  the  possible  data  format  to  identify  causes  for  casualties 
and  oil  spills.  This  is  particularly  important  to  evaluate  the  extent  of  human  and  organiza¬ 
tional  error  in  tanker  operations 

3.2.3.  Application  Example:  CAIP  Report 

In  the  Navigation  and  Vessel  Inspection  Circular  No.  15-91,  [USCG,  1991],  issued  by  the 
U.S.  Co^  Guard  m  Oct.  1991,  guidelines  for  the  development,  use  and  implementation  of 
Cntical  Area  Inspection  Plans  (CAIP)  have  been  provided.  The  requirements  of  the  CAIP’s 
are  intended  to  serve  the  following  purposes: 

•  Act  ^  a  management  tool  that  tracks  the  historical  performance  of  a  vessel, 

identify  problem  areas,  and  provides  a  greater  focus  on  periodic  structural  exami¬ 
nations. 

•  Address  the  cause  of  a  problem,  not  merely  the  symptoms  which  results  in  an  in¬ 
creased  involvement  of  the  vessel’s  management  in  the  solution  of  identified 
structural  and/or  maintenance  problems. 
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.  Assist  surveyors,  inspectors  ^  the  vessel’s  crew  in  ensuring  that  the  vessel  is 
properly  inspected  and  maintained. 

The  decision  to  require  a  CAIP  on  a  single  vessel  or  an 

on  the  vessel’s  history,  its  service,  or  even  the  chmatology  of  the  trade  route.  Curre  y, 
CAIP  is  required  for  ^  vessels  on  the  TAPS  trade  route. 

3.2.3.I.  CAIP  Performance  Elements 

As  outlined  in  enclosure  (2)  of  NVIC-15-91,  [USCG,  1991],  each  CAIP  rqxtrt  should  con- 
tain  the  following  elements: 

•  Executive  Summary 

•  Vessel  Particulars 

.  Historical  Information  -  Structural  feihires,  structural  modifications 

.  Active  Repair  Areas  -  Structural  fiilures,  structural  modifications,  structural 
analyses,  trends 

•  Structural  Inspections  -  Internal,  external 

•  Tank  Coating  Systems 

•  Critical  Area  Inspection  Plan  Update 

The  layout  and  oiganization  of  the  CAIP  report  can  be  chosen  based  on  the  ^ 

ence.  The  use  of  diagrams  and  vessel  plans  to  illustrate  ftactures  and  problem  areas  is  lug  y 

encouraged. 

3  2.3.2.  Evaluation  of  CAIP  Report  Examples 

Six  different  CAIP  reports  from  four  different  operators  were  reviewed  to  determme  the  m- 
flu^m^of^e  reports,  evaluate  the  adherence  to  the  list  of  per&m^e  elements 
Lted  in  enclosure  (2)  ofNVIC-15-91,  [USCG,  1991],  and  to  daemune  the  eff^iv^ss  of 
the  CAIP  re^rts  In  achieving  the  goals  that  have  led  to  the  implementation  of  the  CAIP 

porting  requirement. 

All  reviewed  CAIP  reports  foOow,  in  general,  the  list  ” 

1  /-.<?xrvTr  1  f  01  ruSCG  19911.  The  majority  of  the  CAIP  reports  did  not  pro 

!o  the  cririco/ mpir  o.us,  o«  of  the  m^  con<^ 

rfS^S^Iequirement.  The  description  of  trends  and  causes  for  Mures  was  also  not  ade- 

quately  addressed. 

The  CAIP  reports  either  did  not  include  an  executive  summary  or  did  not  li^  Ae  desisted 
Scd^S^  All  reports  fiicused  on  the  illustration  of  the  vesse  a  Mme  lus^a^ 
ZTveTS^rt  illustrated  general  trends  with  the  help  of  graplucal  dlustranons  of  the 

Mure  distributions. 

Based  on  the  information  content  and  the  representation  style  of  the  six  CAIP  reports 
"idewed,  h  was  concluded  that  none  of  the  reports  completely  satisfied  the  goals  and 

purposes  that  are  inherent  in  the  CAIP  requirement. 
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In  general,  most  CAIP  reports  included  additional  information  (survey  reports,  sample  in¬ 
spection  sheets,  surveying  guidelines,  etc.)  that  reduced  the  effectiveness  CAIP  reports  due  to 
the  increased  volume.  CAIP  reports  are  intended  to  be  short  and  concise  summaries  of  a  ves¬ 
sels  failure  Wstoiy  ivith  special  emphasis  on  critical  repair  areas  and  the  effectiveness  of  per- 
manent  repairs  and  modifications. 


3.2.3.3.  Automated  CAIP  Reports 

Based  on  the  evaluation  of  existing  CAIP  reports,  an  improved  report  format  was  developed 
that  could  be  used  for  the  automated  generation  of  a  CAIP  report  based  on  the  information 
contents  of  the  SSIIS  database. 

3.2.4.  Recommendations  from  SSIIS  1  Project 

Although  existing  database  systems  have  powerful  features  that  allow  the  management  of 
structural  inspection  results  and  the  generation  of  graphical  summaries,  they  are  in  general 

not  designed  to  incorporate  all  the  vessel  information  that  is  related  to  the  design,  inspection 
repair  and  operation  of  tankers.  o  » 

The  review  of  existing  analysis  applications  has  demonstrated  the  scope  of  vessel  information 
necess^  throughout  the  lifetime  of  a  vessel  and  has  given  further  indication  of  the  benefits 
of  a  unified  vessel  information  system. 

Based  on  the  evaluation  of  the  CAIP  reporting  requirements  and  the  definition  of  an  im¬ 
proved  CAIP  format,  it  was  concluded  that  the  SSIIS  database  structure  can  be  used  to  cre- 
ate  ^automated  CAIP  report  generating  process.  For  a  successful  implementation,  however, 
It  will  be  necessary  to  define  and  develop  detailed  representations  of  feilure  locations  within  a 
vessel  This  can  be  done  either  graphically  or  non-graphically. 

A  detafied  definition  of  the  graphics  format  used  for  the  representation  of  the  structural  con- 
fagination  of  a  vessel  must  be  developed.  This  includes  the  level  of  detail  and  the  organization 
of  the  structural  drawings.  It  has  to  be  guaranteed  that  the  location  of  defects  in  a  structural 

drawing  matches  the  location  description  in  the  database. 
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3.3.1 .  NIDDESC  Ship  Product  Model 

The  Naw/Industry  Digital  Data  Exchange  Standards  Committee  (NIDDESC)  addressed  a 

orienuded  brejdown 

[NIDDESC,  1993].  It  is  proposed  that  the  NIDDESC  standard  P 

for  the  Exchange  of  Product  Model  Data  (STEP)  International  Standard. 

The  components  of  STEP  referring  to  the  ship  prod^  “  t^u^T  The 

lion  Protocols  (AP’s)  NIDDESC  has  written  AP’s  for  the  defimtion  of  ship  structures. 

Sta^  S^'^^’s  resent  the  several  stages  in  the  life  cycle  of  a  ship  strumural  system 

from  preliminary  design  through  production  design. 

The  STEP  standard  has  a  layered  archkeeture  in  which  basic  com  demons  are  used  by 
many  industiy  and  product  specific  standards,  such  as  the  NIDDESC  standards. 

The  goal  of  the  NIDDESC  AP’s  is  to  support  the  exchange  of  product  data  representing  the 
ship  structural  system  as  required  by  ship  owners,  designer  and  fabricators. 

The  structure  and  content  of  the  NIDDESC  ship  product  model  are  Muenced  be  the  needs 
rf^7i^  creators  and  users  of  information  over  the  lifecycle  of  the  stop.  An^™- 
tion  structure  that  views  the  ship  as  organized  by  system^  without  regard  for  construct 
practice  or  life-cycle  maintenance  criteria  would  be  unsuitable. 

3.3.2.  Product  orlontatlon  and  systems  orientation 

The  breakdown  of  the  NIDDESC  Ship  Product  Model  is  more  to  a  ^ 

orientated  view  of  the  ship.  The  NIDDESC  Ship  product  model  is  built  upon  the  ISO/STEP 
standard  as  a  foundation  L  central  or  core  concepts  such  as  topology,  geometry  and  prod- 
uct  structure  are  extended  where  necessary. 

Concents  common  to  a  ship’s  product  orientation  such  as  hull  block  assembly,  m  syst™ 
etc  ^  used  consistently  throughout  the  different  components  of  the  stop  product  tnoda 
AppSttoprlcols  are  used  to  extend  the  use  of  STEP  guidelines  mto  more  specialized 
areas.  AP’s  for  the  ship  product  model  are  described  below. 


3.3.2.I.  Ship  product  model  components  .... 

The  NIDDESC  AP’s  are  a  broad  scope  representation  of  the  ship  and  are  divide  mto  t  e 
following  categories  to  facilitate  future  development; 

•  Ship  Geometry, 

•  Ship  Structure  Configuration  Management, 

•  Hull  Product  Structure, 

•  Structural  Parts  (Plates  and  Stiffeners) 

•  Structural  Openings, 


•  Structural  Connections/Joints, 

•  Internal  Subdivision  (compartments  and  zones)  and 

•  Standard  Parts. 

The  MDDESC  AP  development  focused  on  early  stages  of  design  and  manufacturing 
(functional  design,  detail  design  and  production  engineering).  Within  these  stages  support  is 

provided  for  the  activities  of  graphic  presentation,  structural  analysis  and  naval  architectural 
analysis. 

The  selection  of  the  basic  modeling  objects  for  a  ship’s  structure  was  based  on  a  fundamental 
approach  to  object  role  modeling.  The  decks,  transverse  bulkheads  and  longitudinal  bulk¬ 
heads  are  all  similar  in  their  defining  characteristics.  They  all  lie  on  defined  surfaces  and  con¬ 
tain  one  or  more  plate  parts,  have  stiffeners  and  include  other  features  such  as  penetrations. 
To  ease  the  modeling  process  these  elements  are  represented  using  standard  parts. 

The  use  of  standard  parts  allows  the  geometry  to  be  defined  once  but  used  many  times.  It 
should  be  noted  that  a  single  shape  definition  cannot  be  used  to  describe  ship  structural  ele¬ 
ments  over  the  life  cycle  of  the  ship.  Thus  multiple  shape  representations  must  be  used,  for 
example  for  analysis,  design  and  inspection  monitoring. 

Ship  Geometry 

The  geometric  representation  of  a  ship  structure  is  generally  used  as  the  starting  point  for  the 
ship  product  model,  and  therefore,  serves  as  the  foimdation  to  later  shipbuilding  activities. 
The  geometric  model  must  be  robust  enough  to  handle  the  demands  for  a  product  model 
placed  on  it  by  the  various  applications  and  end  users.  Two  areas  of  ship  geometry  are  ad¬ 
dressed  by  this  model:  the  geometry  necessary  to  describe  the  molded  huUform  of  a  ship,  and 
the  geometry  necessary  to  describe  the  structural  component  up  the  ship. 

Hull  Product  Structure 

The  ship  structure  must  be  broken  down  into  smaller  pieces  so  that  it  is  of  sufficient  ‘size’ 
that  it  can  be  readily  managed  and  analyzed.  The  hull  product  structure  refers  to  the  product 
structuring  schemes  represented  within  the  ship  structure  AP’s.  It  is  based  on  the  recognized 
need  for  both  a  functional  system  classification,  appropriate  for  estimating  and  early  stage 
design,  as  well  as  a  product-orientated  work  breakdown  structure,  conforming  to  the  way  the 
ship  is  actually  built. 

Structural  Parts  (Plates  and  Stiffeners) 

The  fundamental  concept  supported  by  the  ship  product  model  contained  in  the  NIDDESC 
AP’s  is  all  structural  parts  contain  a  life  cycle  description.  The  life-cycle  of  a  ship  commences 
with  the  first  design  drawings  and  continues  through  to  decommissioning  and  salvage.  In  the 
early  stages  of  design  and  construction  of  the  vessel,  one  or  more  parts  may  be  completely 
designed  and  manufactured. 

The  information  about  a  part  increases  as  it  progresses  through  the  life  cycle.  It  varies  with 
the  stages  of  design,  construction  and  operation.  This  includes  design  information,  for  exam- 
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pie  analysis  properties,  then  to  construction  as-builts  and  inspection  records.  Once  the  vessel 
is  in  service,  data  includes  inspection,  maintenance  and  repair  information. 

Plate  oarts  are  represented  as  lying  along  geometric  planes.  Stiffener  parts  (used  to  stiffen 
pS:  eCS  Z  either  roller^  «ruded.  built-up  or  otherwise  ftbrioated  s«c®al  profile 
shapes.  Stiffeners  and  beams  are  represented  by  extrudmg  a  cross  section  along 

Structural  Connoctlons/Joints  •  ti. 

The  interfece  between  structural  elements  is  broken  into  connection  and  joint  properties.  The 

to  eapture  the  requirements  of  the  interfice  between  elemems  and 
the  joint  and  de^ribes  the  overall  connection  properties.  The  connection  entity  details  how 
and  where  the  elements  are  joined. 

The  joint  entity  allows  for  the  physical  description  of  the  functional  connection.  The  descnp- 
tion  would  include  such  attributes  as  weld  size,  standard  jomt  detail  reference  and  jo  g 
procedure.  Also  included  is  the  configuration  management  information  such  as  joint  certifica¬ 
tion. 

Internal  Subdivision  (compartments  and  zones) 

The  first  and  most  common  subdivision  is  the  division  of  a  ship  into  compartments.  A  com¬ 
partment  is  usually  integral  with  the  hull  and  has  physical  bounds  fomed  by  the  de^s  and  the 
KSs.  An  einpte  of  compcrtmenls  are  mnks  or  other  voids  which  can  be  isolated 

within  the  ship  Structure. 

A  zone  is  the  abstract  subdivision  of  the  ship  whose  boundaries  may  or  may  not  align  with  the 
geTnSricTrlictural  configuration  of  file  ship.  An  example  of  a  zone,  is  the  cmw  hving 

quarters. 

Standard  Parts 

Standard  parts  are  in  common  use  today  in  various  shipbuilding  structural  CAD  sy^etm,  and 
Lir  use  U  be  supported  by  the  STEP  application  protocol. 

use  of  accepted  structural  details,  for  ease  of  constroction  or  perhaps  because  the  detail  has 
proven  serviceability  and/or  durability. 

3.3.3.  Integrated  Ship  Design 

The  combination  of  graphic  and  non-graphic  information  known  as  product 
data  has  become  the  basis  of  current  CAD/CAM  use  by  many  in  the  U.S.  Nay  ^d  marine 
industry.  Several  shipyards  have  developed  dyign  and  production  systems  on  the  mtegration 
of  traditional  CAD/CAM  systems  with  other  informational  databases. 

The  trend  toward  the  integration  of  previously  separate  database  syte^  for  design  mten- 
als  and  ftbrication  has  resulted  in  a  need  for  better 

nism  capable  of  handling  this  expanded  information  base.  The  NIDDESC/STEP  standar 
provides  a  basis  for  the  development  of  internationally  accepted  protocols. 


M - Ship  Operating  Systems:  A  Case  Study  ■  Stolt  Parcol  Tankars 

A  visit  was  made  to  the  ship  owning  division  of  Stolt  Parcel  Tankers,  in  Houston  TX 
(SPTIH)  during  Janu^  1995  to  review  the  information  systems  currently  under  development 
there.  This  division  is  responsible  for  the  development  and  implementation  of  Information 
Technology  solutions  for  the  operations  of  Stolt  Parcel  Tankers  worldwide  This  section  out- 
lines  the  information  business  systems  under  development  at  SPTIH, 

3.4.1.  Stolt  Parcel  Tankers  -  Background 

Stolt  Nielson  S.A.  provides  distribution  services  worldwide  for  bulk  liquids.  Ocean  going 
transportation  is  provided  by  a  fleet  of  tankers  operating  to  all  major  worldwide  ports.  Stor¬ 
age  terming  are  operated  by  the  company  in  USA,  NW  Europe,  Brazil  and  on  land  transpor¬ 
tation  provided  by  railcars  and  tank  trucks. 

Stolt  P»cel  Tankers  operates  approximately  100  parcel  tankers  from  1300  tons  to  40,000 

deadweight  tons  consisting  of  both  transoceanic  and  coastal  tankers,  and  barges  on  protected 
waterways. 

Within  SPllH  nineteen  people  were  employed  across  all  areas  of  business  systems  develop¬ 
ment.  This  includes  staff  for  hardware  and  communication,  design  and  installation,  software 
development  and  support  personnel.  In  a  recent  three  month  effort,  the  company  was  certi¬ 
fied  on  a  global  basis  to  ISO  9000. 

Reengineering  of  the  existing  business  functions  and  processes  was  clearly  evident.  This  in¬ 
cluded,  for  example,  implementation  of  a  global  communications  network  from  ship  to  shore, 
and  organizational  change  for  purchasing  of  ship  stores. 

3.4.2.  Process  Identification 

The  information  system  and  supporting  programs  developed  within  Stolt  can  be  broadly 
classified  to  M  under  one  of  two  business  processes  shown  in  Table  3.2.  Information  com¬ 
mon  to  processes  and  programs  are  stored  in  a  central  database  titled  SWORD.  Stolt  is  not 
currently  developing  any  systems  to  support  a  structural  maintenance  process. 


Cargo  Operations 

On-Board  Management 

CaBo;  Cargo  booking  system  linked  to 

Stolt  offices  wcffldwide 

MMS;  Marine  Management  System;  used 
to  handle  all  on-board  preventative 
maintenance,  requisition  and  pur¬ 
chasing 

STOW;  Stolt  tankers  operator  workstation 
used  to  match  cargo  and  tanks  on¬ 
board  a  vessel 
under  development 

DOCS;  used  to  generate  reports  for  cargo 
and  personnel  at  ports 
under  development 

Cargomax;  Check  structural  strength  during 
loading/unloading 
under  development 

ICMS;  Instrumentation  of  on-board  me¬ 

chanical  activities  (new-build  ships 
only) 

under  development 

Table  3.2  :  Stolt  Software  to  Support  Business  Processes 
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3.4.2.I.  On-board  Management 

Three  systems  as  shown  in  Table  3.2  are  used  to  handle  on-board  management  ^  . 

viLels  ^The  DOCS  and  ICMS  modules  are  still  under  development,  however  the 
onerational  The  MMS  is  used  for  maintaining  equipment  systems  and  thus  shouW  fo  P 
rSTe  S—  Integrity  Progtan.  (MSIP).  It  fe  therefore  desoibed  m  dettul  below. 

Crucial  to  on-board  ship  managen«nt  is  the  Marine  Management  System  (MMS),  It  is 
to  track  preventive  maintenance  requirements,  and  the  requisitiomiy  and  purehasmg  of  o 
wTln Itoms  This  system  is  in  foe  process  of  being  implemented  across  aU  ve^ls  m  the 
aolt  ri  Fleet,  and  in  January  1995  the  hardware  and  softie  “ 
half  the  fleet.  The  system  has  been  developed  and  raiplemented  in  only  tte  last  12-18  months. 
The  software  was  a  third  party  product  developed  to  Stolt’s  specific  needs. 

The  MMS  aUows  other  modules  to  be  added  which  share  data  with  the  equipment  database 
and  thus  enhance  the  capabilities  of  the  system.  These  modules  mclude. 

.  Inventor,  Management  System  -  this  system  tracks  the  ship  mvento^  and  or- 
g^  Sate  pari  informaion  for  efficient  inventory  conriol.  It  Piowdea  a  de¬ 
railed  database  of  spate  pari  inventory  information  created  from  the  current  mve 

tory  records. 

•  Requisition  Management  System  -  this  system  helps  mintain  correct  inventory 
levels  and  facilitates  the  processing  of  shipboard  requisitions. 

.  Planned  Maintenance  System  -  this  system  allows  the  user  to  schedule  mainte¬ 
nance  standardize  work  procedures,  and  record  equipment  histories.  It  provides  a 
detaUed  database  of  equipment  work  procedures  created  from  the  current  mainte¬ 
nance  records. 

These  modules  share  information  and  work  together  to  make  up  the  MMS.  The  MMS  also 
lo^oUrtes  ior^tion  which  is  entered  on  the  system  for  efficient  transmission  between 
ship  and  shore.  This  feature  allows  the  shore  office  to  access  information  that  is  particular  to 

each  of  the  vessels. 

The  MMS  database  consists  of  technical,  inventory  and  maintenance 
piece^equipment  onboard  the  vessei.  The  equipment  is  coded  to  provide  a  flexible  scheme 
for  organizing  information  and  identifying  specific  pieces  of  equipment. 

An  external  links  option  allows  the  user  to  temporarily  suspend  the  operation  of  the 
^d  r™  an  exteL  software  application.  Example  uses  of  foe  exten^  “”“1 
dude  accessing  a  graphics  program  to  display  illustrations  of  eqmpment  or  a  spare  part,  a 
spreadsheet  program  to  track  requisition  expenses;  and  a  program  to  Ust  safety  notices  an 
additional  information  when  performing  a  work  procedure. 


Equipment  Management  System. 

The  equipment  management  system  is  the  hub  of  the  MMS.  This  module  organizes  informa¬ 
tion  about  the  equipment  and  contains: 

•  technical  and  nameplate  information 

•  equipment  quantity  and  location 

•  spare  parts  information 

•  maintenance  information 

•  equipment  history 

The  organization  of  the  equipment  management  system  allows  all  of  the  information  to  be 
kept  in  one  central  location  and  displayed  in  a  logical  manner.  This  equipment  information  is 

shared  with  the  other  MMS  modules  for  maintaining  inventory  control  and  maintenance  rou¬ 
tines. 

inventory  Management  System 

The  inventory  management  system  is  used  to  organize  and  access  the  spare  parts  information 
associated  with  a  vessel’s  equipment,  such  as  availability,  quantity,  recommended  inventory 
levels,  storage  location  and  pricing  information.  The  inventory  management  system  can  be 
used  for  the  following  activities: 

•  detail  spare  part  records 

•  review  inventory  information 

•  adjust  inventory  levels 

•  generate  labels  for  the  parts 

The  module  displays  information  that  is  common  to  a  complete  class  of  ship,  such  as  equip¬ 
ment  information,  description  and  part  number  in  one  section  of  the  screen.  Another  section 
provides  information  that  is  unique  to  a  particular  vessel,  such  as  quantities  on  order,  mini¬ 
mum  and  maximum  stock  levels,  quantities  in  use  and  storage  locations. 


Requisitions  Management  System. 

The  requisitions  m^agement  system  is  used  to  requisition  parts  and  services  from  the  shore 
office.  The  requisition  management  system  can  be  used  to: 

•  check  the  current  status  of  open  requisitions 

•  requisition  spare  parts  through  the  shore  office 

•  requisition  services  through  the  shore  office 

•  monitor  the  cost  associated  with  the  requisitioned  parts  and  services 

I 

I 

I 

I  - - - - - - - - 
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The  requisition  management  system  provides  an  efficient  way  of  r^uisitiomg  ^  " 
consuiSabies  that  are  short  on  hand,  or  that  are  needed  for  ^  *' 

It  keeps  track  of  parts  and  consumables  ordered,  dates,  prices  and  status  of  pending  orders. 

This  system  helps  to  ensure  that  parts  and  consumables  are  avaitole  for  maintenance  md 
other  Livities,  thereby  streamlining  work  procedures  and  tato.  A  budget  ““^8 
included  to  monhor  the  cost  associated  with  the  requisitioned  parts, 
ices  for  the  different  departments.  The  requishion  can  charged  agamst  the  budget  for  a  p 

ticular  department  or  category. 

Planned  Maintenance  System 

The  planned  maintenance  system  is  used  to  reference  work  procedures  ^d  ^  ® 

ules  for  routine  maintenance  and  long  term  jobs.  It  is  used  to  plan  equipment  ^tenance 
and  for  reviewing  equipment  history.  The  planned  maintenance  system  can  be  used  to. 

•  generate  a  Hst  of  upcoming  or  required  maintenance  routines 

•  document  maintenance  performed  on  the  equipment 

•  track  equipment  running  hours 

•  detail  work  procedures  with  maintenance  information;  standard  maintenance  pro¬ 
cedures  used  throughout  the  Stolt  fleet  are  stored  in  the  system. 

The  work  procedures  screen  contains  detaUed  information  for 

including  the  parts  needed  to  perform  the  maintenance,  the  steps  mvolved  m  the  job  and 
scheduling  information. 

Ouce  maintenance  records  are  in  the  system,  the  planned  maintenance  sy^m  8^ 

erate  maintenance  schedules  for  upcoming  equipment  maintenance,  provide  a  detailed  refer- 
ence  source  for  procedural  information  and  keep  a  record  of  the  equipment  history 

Data  Transmission  , 

The  MMS  soflware  exchanges  information  between  ship  and  shore  sites,  mmntaii^  mirror 
images  of  the  database  at  each  she.  As  users  at  each  she  make  c^es  to  tte  ^  s^h  ^ 
adding  or  modifying  records,  those  changes  are  recorded,  consohdated  with  other  chang  , 

and  put  into  a  transaction  file 

Periodically,  the  transaction  ffles  are  sent  to  shore  via  Rydex.  This  Miismission  is  reeeh-ed 
and  processed  by  a  specially  designed  set  of  programs  m  the  SPTIH  office. 

3A.2.2.  Cargo  Operations/Commercial 

Central  to  Stok’s  parcel  tanker  business  is  the  booking  of  cargoes  for  worldwide  tr^orta- 
tion  The  CaBo  system  has  been  operational  for  the  last  5  years  with  ongimg  modffications. 
T^e  system  is  centered  around  an  IBM  AS400  system  and  all  20  sales  offices  worldwide  are 

connected  to  the  system. 

other  cargo  management  systems  are  being  designed  to  re^e  the  s^ 

tkm.  The  STOW  system  is  being  designed  to  assist  the  ships  master  place  the  orde  e 
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goes  in  the  storage  tanks  on  the  vessel.  Tank  coatings  and  previous  tanks  contents,  are  one  of 
m^y  fectors  that  must  be  considered  before  loading  a  new  cargo.  This  system  helps  the 
ships’  master  plan  tank  contents  and  washing  procedures  after  ofiloading. 

The  Cargomax  system  is  being  interfaced  with  the  STOW  system  to  enable  ship  stress  calcu¬ 
lation  to  be  performed  prior  to  loading.  This  is  being  implemented  to  ensure  an  efficient 
loading  and  ofiloading  sequence  and  to  avoid  overstressing  the  hull  structure. 

3.4.3.  Process  implementation 

The  development  of  the  Marine  Management  System  and  implementation  onboard  Stolt  ves¬ 
sels  has  been  rapid.  The  in^lementation  of  the  system  has  been  fecilitated  by  the  development 
of  a  training  program  for  ship  s  crews  and  the  provision  of  a  help  desk.  Management  is 
committed  to  the  introduction  of  technology  and  has  provided  the  necessary  support  to  aid 
the  implementation. 
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4.  Business  Process  Reengineering 

This  section  is  provided  to  give  a  detailed  background  of  reengineering  which  will  show  that 
the  design  and  unplementation  of  an  information  system  must  be  undertaken  after  existing 
process  flows  are  documented.  Reengineering  of  existing  processes  is  an  essential  part  of  an 
irformation  system  for  ship  structures,  as  it  obtains  maximum  advantage  from  the  introduc¬ 
tion  of  an  advanced  Marine  Structural  Integrity  Program  (MSIP). 

Technology  is  rapidly  changing  the  way  both  information  and  work  is  managed  within  a  busi¬ 
ness.  Radical  change  is  achieved  today  by  many  organi2ations  through  ‘reengineering’  of  ex¬ 
isting  business  processes.  Key  to  this  change  is  the  utilization  of  technology  to  manage  infor¬ 
mation  and  work,  and  the  order  in  which  work  activities  are  organized  to  make  eflBcient  use 
of  technology  [Davenport,  1993;  Manganelli,  1994] 

Process  flows  are  descriptions  of  how  information  and  work  is  organized  within  a  company. 
This  techmque  details  both  inputs  and  outputs,  and  involves  ordering  work  activities  across 
time,  place  and  company  functions.  Business  Process  Reengineering  (BPR),  involves  taking 
an  overall  view  of  a  system  and  completely  re-organizing  the  process  flow. 

The  background  of  reengineering  or  process  innovation  is  outlined  though  a  discussion  of 
processes,  business  strategy,  and  change  enablers.  Steps  chosen  to  innovate  a  business  proc¬ 
ess  are  detailed.  These  steps  include  understanding  the  existing  process  flows  and  activities, 
and  then  by  recognizing  deficiencies,  envisioning  a  new  process  flow  through  the  employment 
of  technology  and  organizational  change. 

Business  process  reengineering,  has  been  used  by  a  large  number  of  companies  to  in^rove 
their  performance  radically.  This  improvement  is  measurable  in  terms  of  financial  and  quality 
goals,  as  well  as  customer  satisfaction,  for  example.  Process  innovation  involves  re-designing 
the  way  a  company  operates.  It  therefore  involves  organizing  the  business  in  terms  of  proc¬ 
esses  that  are  used  to  fulfill  customer  requirements. 

4.1.  Background 

4.1.1.  Innovation 

Business  process  reengineering,  involves  taking  an  overall  view  of  a  system.  Reengineering 
goes  back  to  fundamentals  and  offers  a  radical  and  dramatic  change  to  process  efficiency 
[Hammer,  1993.]  Documentation  of  the  existing  process  flows  highlights  where  improvement 
is  required  and  changes  are  implemented  in  the  new  re-engineered  process.  These  changes  are 
enabled  through  the  use  of  technology,  information  and  organizational  re-structuring. 

4.1.2.  Process  flows 

Process  flows  are  descriptions  of  how  information  and/or  work  flows  within  a  company.  A 
process  flow  diagram  shows  inputs  and  outputs,  and  the  order  of  work  activities  across  time 
and  location.  These  processes  describe  how  the  business  is  conducted,  and  identifies  activities 
where  value  is  added  to  a  product  or  service,  and  where  fiirther  information  is  required. 

Adopting  a  process  orientated  structure  generally  de-emphasizes  the  functional  structure  of 
the  business.  The  structural  maintenance  process  involves  the  sequential  movements  of  in- 
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formation  across  business  fimctions.  For  example,  in  the  inspection, 
activUies  of  a  ship;  fiacture  information  ftom  inspections  b  passed  to  stop  yards  wto  pefft™ 
foe  ir^rmation  ftom  both  foe  inspection  aral  repair  is  eventually  passed  to  certfo- 

cation  and  regulatory  authorities. 

“Process  innovation  demands  that  interfeces  between  functional  or  product  units  either 
i,;^vSi7eWnated,  arfo  that  flows  of  inforrmtion  made  parallel  through  raptd  and 

broad  movements  of  information.”  [Davenport  (1993)] 

Major  processes  include  tasks  that  draw  on  multiple  functional  skills.  Adoptmg  ^ 
flow  tovation  change  therefore  involves  cross-functional  change  and  cross-organizational 

change. 

4.1.3.  Process  selection 

To  select  a  process  for  innovation  a  company  must  have  clearly  identTJ  all  “f 

and  activitil  Defining  a  few  processes  broadly  is  easier  to  mamtam  focus  to  aclneve  rad  c  j 

change.  Selecting  and  tanking  the  processes  for  innovation  depends  on  where  the  greatest 

benefit  can  be  gained. 

Selecting  a  process  with  many  inter-functional  steps  will  provide  the  most  lever^e  for 
change  Therefore,  the  aim  is  to  specify  company  processes  m  broad  terms.  Broadly  defin 
pTSser^vide  greater  opportlties,  but  are  more  difficult  to  understand,  elucidate,  and 

change. 

The  relevance  of  each  process  to  the  company  strategy  can  be  assessed.  This  defines  how  im¬ 
portant  any  one  process  is  to  achieving  company  goals.  This  ranking  of 
provides  a  guide  to  process  selection  for  innovation.  Short  term  eiyenditure  must  ofi^et  me¬ 
dium  to  long  term  performance  improvements  and  changes  must  be  financi  y  accom 
Thus  the  goal  will  be  to  innovate  those  processes  that  will  profit  the  conqiany  the  mos  . 

Customers  are  a  valuable  source  of  information  used  in  reviewing  the  processes  for  change 
Existing  process  criteria  can  be  assessed  through  customer  interviews  to  detenmne  ciment 
rCco^gs.  CiBtomcrs  can  also  assist  in  foe  creation  of  a  new  process  wsio^d 
identification  of  process  objectives.  Process  innovations  often  mvolve  not  only  internal  but 
also  external  organizational  changes.  Customers  and  suppUers  must  therefore  be  mvolved  in 

the  new  process  vision. 

4.1.4.  Strategy  &  Process  Visions 

Company  strategies  emphasize  the  loi^  term  goals  and  directions  of  a  company.  It  is^^^th 
thesf  that  process  innovation  starts.  Strategies  provide  the  focus  for  the  development  o 
process  change  and  the  creation  of  future  process  visions.  These  process  visions  cornet  of 
measurable  objectives  and  define  the  attributes  for  individual  processes,  see  Figure  4.1. 
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Figure  4.1  :  Strategies,  Visions,  Objectives  and  Attributes 

Process  objectives  describe  the  goals  of  the  process  in  detail,  and  provide  a  clear  definition  of 
\^iiat  the  new  process  will  achieve.  It  is  clear  that  business  strategy  and  process  objectives 
have  a  common  theme. 

Emphasis  on  strategy  and  process  objectives  provides  a  clear  statement  of  required  achieve¬ 
ments.  For  successful  implementation  of  process  innovation  the  motivation  for  change  must 
be  strong.  A  well  defined  strategy  is  therefore  an  excellent  place  for  the  establishment  of 
process  objectives. 

Process  atMbutes  establish  the  way  in  which  the  new  process  will  be  implemented.  This  en¬ 
tails  describing  the  information  technology  required  (e.g.  inspection  recording  devices)  and 
the  organizational  changes  (e.g.  empowerment  of  employees)  required. 

4.2.  Enablors  of  process  innovation 

Enablers  of  process  innovation  are  mechanisms  that  provide  the  means  for  process  change. 
This  is  achieved  through  extensive  use  of  information  technology  as  well  as  changes  in  organ¬ 
izational  structure. 

A  clear  distinction  must  be  made  between  information  and  information  technology.  Informa¬ 
tion  is  mampulated  or  handled  by  information  technology;  information  is  recorded,  stored, 
analyzed  and  reported  by  information  technology. 

4.2.1.  Information  Technology 

Information  Technology  (IT)  is  a  combination  of  the  following  technologies:  hardware,  soft¬ 
ware,  communication,  plus  information  used  together  to  control  and/or  manage  a  process. 

Information  technology  is  used  to  integrate  information  within  a  process  flow.  One  form  of 
IT,  automation  which  is  the  replacement  of  human-power  by  technology,  has  been  used  ex¬ 
tensively  by  industry  to  increase  eflBciency.  However,  it  has  been  introduced  with  a  focus  on 
improving  the  efficiency  of  explicit  functional  activities  rather  than  improving  the  overall 
process  flow.  Automation  of  fimctional  activities  may  only  yield  small  benefits  since  technol¬ 
ogy  is  introduced  without  being  integrated  across  the  process  flow. 
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In  the  past  the  tendency  of  softtvare  development  has  been  to  support  a  functional  view  of 
business  activities.  This  has  resulted  in  programs  written  to  support  activities  m  a  procep  that 
same  inputs  and  as  a  result  data  has  been  trapped  within  funotmnai  actmtt^ 
With  the  implementation  of  a  process  view  the  information  requirements  must  support  the 

process  flow. 

It  has  been  identified  above  that  information  technology  and  the  use  of  infonmtion  must  be 
LJ^mentei  acL  fimctional  divisions  to  achieve  innovation.  Therefore,  the  mtroduction  of 
information  technology  within  a  process  must  be  supported  by  organizational  changes. 

Advances  in  communication  technologies,  such  as  the  increasing  use  of  networks  h^  now 
made  integration  of  information  technology  feasible.  A  ship  at 

of  information  to  and  fi-om  shore  quickly  and  easily.  The  use  of  land,  ceUular  and  ^telhte 
]Ls  has  resulted  in  truly  world  wide  communications  making  the  effective  electromc  transfer 
and  integration  of  information  possible. 


Impact 

Explanation 

Examples 

Automational 

eliminating  human  labor  from  a  process 

manufecture  :  cad,  computer-aided  or  inte¬ 
grated  manufeicturing,  materials  handling, 
robotics 

control :  telemetry,  process  control,  AI,  feed¬ 
back,  command  and  control 
identify  :  bar  codes,  magnetic  strips,  transpon¬ 
ders 

informational 

capturing  process  information  for  purposes 
of  understanding 

Capture  and  document :  image,  (lata  storage, 
microfilm 

sequential 

changing  process  sequence,  or  enablmg 
parallelism 

share  expertise  :  knowledge  based  expert  sys¬ 
tems,  bulletin  boards 

share  information  :  data  bases,  external  infor¬ 
mation  services  and  networks 

tracking  1 

closely  monitoring  process  status  and  ob¬ 
jects 

analytical 

improving  analysis  of  information  and 
decision  making 

analyze  :  simulations,  correlations,  trends, 
spreadsheets,  budget,  or  standard  vs.  actual 

informate  :  telemetiy',  on-line  access 
manage  :  decision  support,  management  in¬ 
formation 

geographical 

coordinating  processes  across  distances 

communicate  :  data  communication,  teleph¬ 
ony,  video,  networks 

provide  mobility  :  cellular  telephone,  laptop  or 
handheld  computers 

integrative 

coordination  between  task  and  processes 

human  interfece  :  graphics,  voice  recogni¬ 
tion/response,  video,  pen  based 

intellectual 

capturing  and  distributing  intellectual  assets 

disintermediating 

eliminating  intermediaries  from  a  process 

elli,  1994] 


4.2.2.  Information 

Information  technology  assets  are  managed  as  company  capital;  they  are  for  example,  in¬ 
cluded  in  budgets,  depreciated  and  even  allowed  for  in  oflBce  space  requirements.  The  con¬ 
cept  of  IT  as  a  physical  asset  is  easy  for  managers  to  understand.  However,  the  information 
held  within  a  company  is  often  poorly  organized.  Information  not  held  on  paper  but  in  elec¬ 
tronic  form  is  often  not  well  managed  even  by  organizations  with  quality  certification. 

The  management  of  information  is  largely  ignored,  yet  it  is  the  information  that  is  largely  used 
within  process  innovation  efibrts.  Information  can  be  used  in  a  variety  of  ways  to  increase 
efficiency  and  bring  about  effective  process  change.  Examples  include: 

•  Process  integration;  the  use  of  information  to  integrate  activities  across  time  and 
place,  and  different  processes. 

•  Process  customization;  the  use  of  information  to  customize  an  output. 

The  aim  in  the  management  of  IT  is  to  develop  systems  which  integrate  information  on  a 
process  level.  Traditional  views  of  software  development  has  taken  a  fiinctional  approach  to 
information  requirements.  Information  processes  are  largely  unstructured  and  moving  to 
structured  process  is  itself  an  innovation  for  many  companies. 

4.2.3.  Human  and  Organizational  Resources 

Changes  in  organizational  structure  to  gain  maximum  advantage  fi-om  IT  include  utilization  of 
the  following: 

•  Team  structure  approach;  group  problem  solving. 

•  Empowemient  of  individuals;  using  technology  to  supply  individuals  rapid  access 
to  iirfoiwtion  to  solve  problems  immediately.  Also  used  to  compile  specialist  ac¬ 
tivities  into  manageable  tasks. 

•  Flattened  organizational  structures;  reduction  in  management  levels  as  a  result  of 
team  working  and  employee  empowerment,  cultural  changes  to  management 
processes. 

What  typifies  process  innovation  are  the  organizational  changes  required  to  yield  mavimnTn 
advantage  fi'om  the  implementation  of  information  technology  across  a  process.  Cross¬ 
functional  organizational  changes  are  implemented  from  the  top  down  within  a  company. 
These  changes  must  be  supported  and  executed  by  upper  management.  Consequently  upper 
inanagenient  support  for  reengineering  is  crucial  for  success. 

Qu^ty  orientated  improvements  are  not  radical  turn-arounds  in  the  way  a  company  conducts 
business.  Improvements  operate  on  a  functional  level  where-as  process  innovations  look  be¬ 
yond  company  functions.  Innovation  stresses  cross-function  activities  and  thus  requires  sig¬ 
nificant  organization  change  which  must  be  supported  from  the  top  level  of  management 
within  a  company. 
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A.3.  Existing  process  flow 

As  obvious  as  it  may  appear,  it  is  crucial  to  understand  the  eidst^  process  Aow.  D«^ 
the  etdstiiui  process  flow  encourages  communication  of  ideas  and  a  common  imderstandit* 
<^pm"L  understlding  of  the  process  flow  higMghta  possible  ch^«^ 
^Sexfeiing  problems.  It  also  stresses  the  magnitude  of  the  changes  required  m  the 

implementation  of  the  new  process. 

4.3.1.  Identify  existing  activities 

A  common  problem  in  many  companies  is  that  of  a  general  lack  of  detailed  knowledge  of 
A  common  prooicu  ui  uuu^  f  Altemativelv  a  functional  view  of  mtemal  de¬ 

business  processes  m  use  [Davenport,  1993].  Alternatively,  a  u 

nartments  mav  be  known  but  the  cross-functional  relationship  between  them  will  not  }x  we 
Understood.  Personnel  often  have  Uttle  imderstanding  of  the  role  performed  by  other  dep 
ments,  let  alone  the  detailed  work  activities. 

The  descriotion  of  the  process  flow  should  identify  value  adding  activities,  waiting  tmes  and 
bottleneck  Also  to  be  detailed  are  customer/suppUer  interaction,  rfoinces  us^,  and  t  e 
Sit  in  the  process.  Assessment  of  the  existing  IT  configuration  should  mclude  existmg  ap¬ 
plications,  databases,  technologies  and  standards. 

A  description  of  the  current  process  flow  and  identification  of  the  existing  activities  can  be 
used  to: 

.  measure  the  existing  process  in  terms  ofthe  new  process  objectives 

•  assess  the  existing  process  in  terms  of  the  new  process  attributes 

•  identify  problems  or  shortcomings  with  the  existing  process 

•  identify  short  term  in^rovements  in  the  existing  process 

•  assess  existing  information  technology 

•  assess  existing  organizational  structure 

4.3.2.  Improving  the  Existing  Process 

rhfinoes  can  be  made  to  processes  which  have  not  been  selected  for  reengineering  by  in^le- 
^K  taaemeSmlprLments.  These  can  be  interim  fixes  untU  resources  are  aUocated  to 
design^  new  process^  Making  improvements  immediately  before  i^lementmg  process  in¬ 
novation  may  not  be  worthwhile  as  too  many  changes  may  be  required. 

Incremental  improvements  may  be  recognized  in  processes  not 

These  improvements  should  certainly  be  undertaken,  ^  tet^ln- 

innovation  is  planned.  Organizations  must  be  able  to  separate  the  differences  betwee 

provements  and  innovation. 

Information  systems  can  require  considerable  time  to  change  as  new  software  is  written  ^ 
ctSe  Iptation  of  existing  or  the  purchase  of  third  par^  »ftware  whtch  c»  be  ^ 
Sfo  suh  the  tadividual  application  can  be  a  solution  to  speed  the  process  mnovation  mf 

plementation. 


Changes  in  company  organization  can  take  considerable  effort  and  persistence  especiaUy  in 
fcger  organizations  where  considerable  company  culture  has  developed. 


4.4.  New  process  flow 

Mer  the  company’s  strategies  and  goals  are  established,  its  processes  identified,  and  its  exist- 
mg  process  flows  documented,  the  next  task  is  to  change  and  innovate.  The  process  activities 
and  resources  have  been  identified  and  flaws  recognized;  the  challenge  is  now  to  design  a 
new  process  flow. 

4.4.1 .  Envision  of  the  now  process  flow 

The  goals  of  the  new  process  design  are  to  achieve  a  more  efficient  and  more  productive 
process  flow.  Although  individual  activities  may  increase  in  complexity,  the  total  number  of 
activities  will  be  reduced.  The  new  process  will  perform  tasks  in  a  logical  order  such  that 
work  is  managed  effectively,  and  tracked  easily  to  maintain  and  check  progress. 

Mth  the  introduction  of  IT,  redundant  steps  are  eliminated  and  parallel  processing  imple¬ 
mented  to  reduce  tettlenecks  and  idle  time.  The  use  of  communication  technology  to  gather 
information  fi-om  different  areas  reduces  the  number  of  work  locations. 

At  an  organizational  level,  jobs  may  be  combined,  support  may  be  outsourced,  and  decision 
making  brought  up-firont.  The  use  of  IT  results  in  more  useful  information  supplied  to  work¬ 
ers.  This  enables  work  on  multiple  tasks  and  quicker  decision  making.  The  use  of  expert  sys¬ 
tems  (rule  based  systems)  and  neural  networks  (learnt  systems)  are  examples  of  technology 
developed  to  inform  humans  for  faster  decision  making. 

The  envisioning  of  a  new  process  consists  of  creative  teamwork  and  brainstorming  for  new 
ideas.  Benchmarking,  the  comparison  of  work  practices  among  other  companies,  is  one 
source  of  new  ideas.  Benchmarking  either  competitors  or  companies  in  other  industries  will 
uncover  their  approaches  to  problem  solving. 

4.4.2.  Benchmarking 

Benchmarking  is  a  very  useful  tool  for  process  innovation.  Researching  what  other  compa- 
mes^ve  tried  and  their  subsequent  success  (if  any),  is  of  enormous  benefit.  One  idea  is 
benchr^k  outside  one’s  industry  with  a  ‘best  of  company  (a  company  that  is  a  recognized 
leader  m  the  implementation  of  a  similar  process  or  technology.)  These  companies  are  often 
detailed  in  busiriess  papers  and  journals,  and  may  even  participate  in  open  discussion  of  their 

process  innovation.  Another  solution  commonly  adopted  is  the  use  of  external  management 
consultants. 

4.4.3.  Brainstorming 

Br^torming  in  a  group  environment  is  a  tried  and  tested  method  used  to  obtain  solutions  to 
problems.  Brainstorming  in  teams  that  include  the  key  stakeholders  will  assure  that  ideas  dis- 
cussed  me  feasible.  Coming  up  with  ‘pie  in  the  s^’  ideals  using  fer  fetched  technology 
should  be  encouraged  as  total  change  process  change  often  results  in  innovation. 


Team  work  wffl  also  detaU  the  risks  and  benefits  of  process  implementation  with  the  intro- 
IS^orora"ocess.  Risks  can  be  assessed  on  development  atri  chang^ver  ^ 
implementation  of  new  technology,  as  well  as  the  abiUty  of  tte  ^ 

the  process  changes.  Organizational  changes  both  at  a  structural  level  and  at  an  mdividual 

employee  level  must  be  assessed. 

Prntotvnine  the  new  process  using  manual  methods  is  useful  to  estimate  process  benefits. 
^S^fil^sSdteassesse/against  the  process  objectives  to  determine  tf  company 
performance  wffl  be  radically  enhanced  with  the  introduction  of  the  new  process. 

4.4.4.  Detailing  the  process  vision;  the  solution 

Once  the  new  process  vision  has  been  identified  through  benchmarking  and  brainstommg, 
md  the  risks  a^d  benefits  assessed  as  weU  as  the  feasibiUty  proven,  the  new  process  visio 

can  be  detailed  into  a  solution. 

4.4.4.1.  Technology  &  Information 

During  the  detailing  of  the  new  process,  benchmarking  and  review  of  the  tecteal  ^sources 
S  what  technologies  are  available  for  use.  This  includes  hardware,  software  and  n«- 
working  tools  to  integrate  and  customize  information. 

The  aim  is  to  develop  specifications  for  the  design  of  technology  solutions.  Infonmtion  ram- 
agement  or  informatfon  engineering  (IE)  starts  with  the  definition  of  the  information  require¬ 
ments  These  requirements  must  be  exhaustively  defined  though  all 
avoid  dupUcation  of  data.  IE  moves  through  the  collection,  analyzmg  and  utilization 

information  and  data  linkages. 

Extensive  use  of  information  systems  and/or  databases  is  made  to  mamge 

aUows  access  and  updating  of  information  by  software  appUcations  wntten  to  n^age  an 

“a  proc"'  The  specifications  for  these  appUcations  must  1.  written  and  the  user  mter- 

fiice,  often  referred  to  as  the  technology/human  interface,  designed. 

Computer  aided  software  engineering  (CASE)  toois  are  extensively  in  the  IE  “ 

^  software  deveiopment.  These  tools  allow  data  linkages  to  be  graphtcally  estabhshed 

and  modeled,  and  data  analysis  routines  written  quickly. 

The  chaUenge  is  to  integrate  effectively  IT,  both  horizontaUy  across  business  functions  and 
^^ic*  thfough  manag^  levels.  Detailing  information  and  work  pmcess  flows  ytelds  an 
efficiem  order  of  activities  across  business  fimetions.  The  design  of  techmcai  sohitton  details 
elements  of  IT  identified  in  Section  4.2.1  and  utilized  m  the  new  process  vision. 

4.4.4.2.  Organizational 

Designing  a  new  organizational  structure  to  support  the  new  process  wsion  revolves  ^omd 
SrSon  of  a  company  focused  on  its  processes.  Employees  work  on  bro^^  deto^ 
tasks  through  the  use  of  technology  and  are  able  to  complete  a  wider  range  of  actmt  ies  mter- 
Unked  with^technology.  The  elimination  of  specialized  tasks  requirmg  management  levels 
suits  in  the  reduction  of  the  number  of  required  levels. 


The  design  of  organizational  changes  defines  the  new  organizational  layout;  this  consists  of 
the  defimtion  of  management/employee  structure  and  the  identification  of  required  skills.  Job 
descriptions  should  identify  training  requirements  of  existing  employees  and  required  acquisi¬ 
tion  of  new  skilled  personnel. 

4.4.5.  Implementation  and  Performance 

The  transition  to  a  new  process  design  within  a  company  requires  considerable  efibrt  and  re¬ 
sources.  Process  changes  will  be  significant  and  therefore  an  assessment  of  the  company’s’ 
reaction  to  change  must  be  undertaken.  An  implementation  or  transition  plan  must  be  drawn. 

4.4. 5.1.  Transition  pian 

There  are  three  approaches  to  the  implementation  of  process  change  within  an  organization: 

•  Pilot,  trial  of  a  new  process  parallel  to  the  existing  process.  Once  the  new  process 
runs  smoothly,  the  old  process  can  be  discontinued. 

•  Straight-out-change;  discard  the  old  process  and  implement  the  new  process  in  an 
overnight  change.  Problems  that  arise  in  the  new  process  may  result  in  initial 
shortcomings,  but  they  hopefully  can  be  eliminated  quickly. 

•  Phased,  implement  gradual  changes  over  time.  This  reduces  problems  to  a  man¬ 
ageable  level  and  avoids  the  numerous  problems  of  a  straight-out-change. 

In  any  transition  or  implementation  plan,  the  introduction  of  new  technology  must  be  accom¬ 
panied  by  training. 

important  role  of  management  in  the  implementation  of  new  processes  is  the  communica¬ 
tion  of  company’s  goals  and  the  description  of  why  changes  are  necessary.  A  responsive 
workforce  results  fi-om  open  lines  of  communication  between  management  and  employees. 
Employees  informed  of  changes,  and  kept  aware  of  the  transition  wiU  help  the  company  to 
change  as  they  will  recognize  the  benefits  of  overall  improvement. 

4.4.5.2.  Communication 

Clear  communication  between  management  and  employees  are  essential.  From  the  com¬ 
mencement  of  innovation  efibrts,  employees  informed  of  goals  and  objectives  will  make  ef¬ 
forts  to  identify  required  changes,  and  will  assess  the  proposed  changes.  This  feedback  in  the 
innovation  process  loop  is  essential  to  ensure  maximum  leverage  fi-om  the  proposed  process 
change. 

Feedback  is  also  required  after  the  implementation  of  the  new  process  to  eliminate  glitches 
and  bugs  in  the  system.  This  feedback  comes  not  only  fi-om  employees  but  also  fi-om  custom¬ 
ers.  Process  innovation  starts  with  identifying  ways  of  improving  customer  satisfaction  and 
must  end  with  ensuring  that  these  are  achieved. 
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4.4.5.3.  Performance  measures 

Customers  provide  the  best  indicator  of  process  improvement.  Company  performance,  ^ 
previously  dbcussed,  is  ultimately  determined  by  tottom  line  profit.  Increased  customer  satis- 
fection  and  efficient  process  flows  will  increase  this  profit. 

The  assessment  of  process  objectives  and  company  strategy  with  the  changed  process  flow 
will  also  provide  a  measure  of  innovation  success. 

AS.  Conclusions 

What  makes  reengineering  stand-out  among  business  trends  is  the  potentW  f” 
^vements  m^e  to  the  existing  organizational  structures  are  genaafiy 
namwly  defined  flmctional  activities.  Process  innovation  however  takes  a  cross-fiinctio 

approach  in  solving  problems. 

Process  innovation  takes  a  system  overview  in  the  appUcation  of  information  technology  (IT) 
fo  proLm  solution  The  Jegration  of  information  across  all 

functions  is  only  possible  after  the  identification  of  the  processes  where  formation  is  used. 
Existing  processes  must  be  clearly  enumerated  before  the  development  of  new  process  flows 
is  initiated,  and  IT  requirements  are  detailed. 

The  use  of  IT  in  process  innovation  is  maximized  with  the  incorporation  of  orgai^tional 
^ges  to  boo”  process  and  business  performance.  The  introduction  of  information  man- 
aeeiint  systems  that  do  not  take  advantage  of  organizational  changes  to  collect,  analj^e  and 
Slize  process  information  are,  at  best,  only  ^utomational  improijments  of 
ties  The  identification  of  business  processes,  the  information  used  therein  and  the  ^^ated  or 
ganizational  changes  are  therefore  essential  to  develop  a  useful  and  effective  informati 

management  tool. 


5.  Information  Systems 

Reengineering  and  the  development  of  an  information  system  have  many  overlapping  ele¬ 
ments.  This  is  illustrated  in  Figure  5.1,  The  evolution  of  an  integrated  business  information 

system  from  conception  to  implementation  uses  many  features  of  business  process  reei^eer- 
ing. 

T^e  development  of  an  information  system  is  comprised  of  four  phases  [Mylls,  1993],  very 
similar  to  that  of  a  marine  structure:-  ’ 

•  Plan^g  is  the  why;  providing  the  direction  of  the  system  development  and  de¬ 
termines  who  are  the  owners  and  users  of  the  system. 

•  Analysis  is  the  what;  determining  what  must  be  accomplished,  through  detailing 
system  requirements. 

•  Design  is  the  how;  deciding  how  the  system  operates  in  the  organization. 

•  Construction  is  the  building  and  testing  of  the  system. 

All  four  phases  are  related  and  dependent  upon  each  other  because  of  constantly  changing 
requirements.  Each  phase  cycles  within  itself  and  with  other  phases.  Planning  determines  the 
priorities  for  subsequent  analysis.  Analysis  provides  the  requirements  for  the  systems  to  be 
designed.^  The  designed  systems  are  then  Constructed.  Reengineering  activities  are  primarily 
involved  in  the  planning  and  analysis  of  information  system  development. 


Re-engineering 

Informati(Mi  Technology 
Organizational  Change 


Figure  5,1  :  Reengineering  and  Information  Engineering 

The  creation  of  a  business  information  system,  evolved  through  each  of  the  phases,  and  with 
a  minimum  number  of  adjustment  cycles,  will  ensure  an  optimum  system.  This  allows  for  in- 


formation  sharing  between  functions,  that  is  cross-functional  integration 
orous  development  of  the  system  architecture  will  ensure  the  system  developed  matches  th 
objectives  established  at  the  start  of  the  project.  Detailing  the  system  development  phases  en¬ 
sures  that  a  business  system  is  created  to  match  busmess  requirements. 

Business  objectives  are  met  throi#  the  supply  of  correct  coiBistent  ^ 

Information  engineering  uses  the  interaction  of  data  and  usmess  ac  ivi  i 
plications  and  systems  to  supply  information. 

From  planning  to  constructkm,  the  development  of  four  levels  of  information  system  archhec- 
tures  are  progressively  detailed,  these  are 

.  Infonnation  Technology;  the  information  technology  architecture  is  ^  descripti^ 
of  the  hardware,  software  and  communication  configuration.  For  example  tliK 
may  include  a  description  of  the  cUent/server  system  and  associated  support  plat¬ 
forms. 

•  Infonnation;  the  information  architecture  is  a  result  of  gathering  the  information 
needs  and  relationships  between  busmess  functions  and  activities. 

•  Organizational;  the  organizational  architecture  is  estabUshed  largely  as  a  of 
reSgineering  efforts.  New  jobs  may  be  created  when  previously  activities  are 
consolidated  through  the  use  of  infonnation  technology  and  team  workmg. 

.  AppBcation  Arehitectnre;  the  appUcation  architecture  is  a  description  of  how  the 
information  system  will  appear  to  the  user.  This  encompasses  the  gathermg  or  e 
try  of  data  to  the  reporting  of  analysis  results. 

The  stages  of  information  system  design  and  the  architecture  are  represented  m  Fi^e  5.2 


Architectures 

Phases 

information 

technology 

information 

application 

planning 

hardware 

software 

communication 

Business 

Systems 

analysis 

existing 

processes 

1 _ _ '■  - - ^ 

design 

procedures 

modules 

user  interface 
reports 

construction 

databases 

programs 

user  interface 
reports 

new  job  roles 


restructuring 


change 


Figure  5.2  ;  Development  of  an  Infonnation  System 


5.1,  Planning 

The  objective  of  planning  the  development  of  an  information  system  is  to  reflect  where  the 
enterprise  is  going,  not  where  it  currently  is.  Data  must  be  organized  to  satisfy  the  informa¬ 
tional  needs  throughout  the  oi^anization,  and  to  make  the  commitment  to  data  sharing. 

If  the  information  system  is  developed  with  the  ideals  of  reengineering,  then  prior  to  the 
planning  phase  business  strategies  and  objectives  will  have  been  established.  These  are  used 
to  identify  priority  areas  within  the  company  and  hence  identify  potential  business  systems 
where  significant  benefit  can  be  realized. 

The  planning  phase  identifies,  through  benchmarking  and  other  methods,  the  information 
technology  (IT)  that  is  available.  IT,  as  previously  discussed,  consists  of  computer  hardware, 
software  and  communication. 

Planning  identifies  current  business  fimctions.  For  example  they  include  the  transportation  of 
cargo  or  the  inspection  of  vessels.  Data  entities  are  the  description  of  information  within  an 
activity,  such  as  the  inspection  records  or  the  description  of  the  ship  geometry. 

5.2.  Analysis 

The  analysis  phase  of  information  system  development  details  the  processes  used  to  match 
the  company  strategy  and  fulfifl  the  business  objectives.  Detailing  the  processes  and  using 
business  fimctions  detailed  within  the  planning  phase,  the  re-engineered  information  flows  can 
be  developed.  Identifying  potential  innovative  changes  within  the  organization  allows  for 
maximum  benefit  to  be  derived  from  the  implementation  of  new  information  technology. 

The  analysis  phase  produces  data  and  activity  models  and  user  views  through  prototyping. 
Data  and  activity  models  make  use  of  computer  aided  software  engineering  (CASE)  tools  to 
develop  the  information  relationships  within  processes,  fimctions  and  associated  activities.  On 
a  detailed  level,  data  models  are  developed  to  show  relationships  between  activities. 

On  a  simple  level  the  information  relationships  between  fimctions  and  entities  can  be  repre¬ 
sented  in  a  matrix  format.  The  intersection  cefi  defines  the  action  the  fimction  performs  on 
the  entity  type:  create,  read,  update  or  delete.  This  is  illustrated  in  the  following  chapter  for 
the  breakdown  of  the  SSIIS  information  requirements. 

Prototypes  are  effective  in  obtaining  comments  from  departments  and  personnel  who  will  be 
res^nsible  for  usmg  the  new  system.  These  comments  and  ideas  are  carried  forward  into  the 
design  phase.  During  the  analysis  phase,  the  business  system  can  be  subdivided  into  separate 
design  phase  projects. 

6.3.  Design 

In  the  design  ph^  of  information  system  development,  the  specifications  of  the  modules  are 
fully  detailed.  This  includes  defining  user  interfeces,  that  is  the  forms  used  by  the  user  to  enter 

data,  as  well  as  reports  used  to  summarize  the  data  ultimately  used  in  the  decision  making 
process. 
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During  this  stage  the  role  of  the  information  system  is  developed.  The  informatton  system 
support  decision  makii^  on  various  levels  as  shown  in  Figure  5.3^  With  inerting 
mhig  effort,  increased  support  can  be  obtained  from  the  system.  At  a  sunphstic  level  this  ^ 
eludes  general  summary  information  providing  ‘what  if?’  answers  A  fully  ^ 

system  can  provide  decision  support  to  the  non-expert  via  the  knowledge  coded  into  the  sys- 

tern. 
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Figure  5.3  :  Stages  of  Information  System  Development 


S.4.  Hardware/Sofftware  Considerations 

The  implementation  of  an  information  system  must  enable  data  to  be  accessed  by  a  large 
number  of  persons  over  a  wide  range  of  locations.  The  use  of  relational  datab^es  and  ch- 
ent/server  system  architecture  are  examples  of  software  and  hardware  technologies  that  have 
enabled  multi-user  information  system  developments. 

6.4.1.  Relational  Databases  and  Structured  Query  Language  (SQL) 

Relational  databases  consist  of  storing  data  in  two  dimensional  tables.  Table  rows  represent 
records  of  data,  while  table  columns  represent  fields  in  the  record.  The  column  that  >^que  y 
identifies  a  particular  feet  upon  which  the  table  is  based  represents  a  uraque,  primary  key.  o 
eliminate  data  redundancy  designers  perform  the  normalization  process,  which  ^  to  put  aU 
data  about  the  primary  key  in  the  same  table  where  the  key  is  defined.  A  relational  datab^ 
usually  consists  of  many  tables  where  fields  are  joined  by  relations  or  links  to  form  complex 

data  structures. 

Structured  Query  Language  (SQL)  is  a  defeult  language  used  for  data  access  and  manipula¬ 
tion  in  relational  database  management  system  (RDBMS).  SQL  allows  u^rs  to  teU  the 
RDBMS  only  what  data  is  required,  and  what  manipulations  are  to  be  done,  but  not  how  to 
perform  these  manipulations.  SQL  is  the  sole  means  of  providing  access  to  data  m  a  relational 

database. 
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5.4.2.  Client/server  Architecture 

The  client/server  IT  architecture  organizes  personal  computers  (PCs)  and  local  area  networks 
(LANs)  from  workgroup  file  servers  to  mainframes  into  a  flexible  and  efficient  system.  It  en¬ 
sures  that  processing  power  is  distributed  to  all  nodes  in  the  system  and  file  storage  remains 
in  an  central  location. 

The  clients  are  the  PCs  or  workstations,  attached  to  a  network  and  are  used  to  access  net¬ 
work  resources.  The  client  typically  runs  a  graphical  user  interfece  (GUI)  which  accesses  the 
resources  of  the  server .  The  servers  provide  multiple  clients  access  to  shared  databases,  other 
files  and  communication  resources. 

The  clients  pass  queries  to  the  servers  and  the  client  performs  all  the  user  interfece  activities 
such  as  controlling  input  and  output  forms  and  reports  and  presentation  of  the  data  supplied 
back  the  server.  Multiple  clients  can  access  the  same  information  from  the  server.  Tasks  are 
split  into  two  activities,  the  front-end  performed  by  the  client  and  back-end  by  the  server. 

Servers  perform  the  file  sharing,  storage  and  retrieval  of  information,  network  and  document 
management  and  provide  gateway  fimctions  for  internal  and  external  flows  of  informatioa 
The  client/server  architectme  divides  an  application  into  separate  processes  operating  on 
separate  machines  connected  over  an  network.  An  application  designer  determines  which 
tasks  will  be  performed  by  the  client  and  which  by  the  server. 

The  advantages  of  client/server  architectures  are  as  follows 

•  they  are  open  systems,  allowing  IT  managers  to  pick  and  choose  hardware,  soft¬ 
ware  and  services  from  various  vendors. 

•  they  can  easily  grow  and  expand  and  it  is  easy  to  modernize  the  system  as  re¬ 
quirements  change. 

•  they  are  efficient,  the  system  provides  the  power  to  get  things  done  without  mo¬ 
nopolizing  resources.  End  users  are  empowered  to  work  locally. 

“An  enterprise-wide  client/server  architecture  provides  total  integration  of  departmental  and 
corporate  information  system  (IS)  resources.  This  allows  applications  to  span  the  enterprise 
and  leverage  both  central  and  end-user  systems.  It  provides  better  control  and  security  over 
data  in  a  distributed  environment.  By  implementing  client/server  computing  as  the  architec¬ 
ture  for  enterprise-wide  information  systems,  IS  organizations  can  maximize  the  value  of  in¬ 
formation  by  increasing  its  availability.  Enterprise  client/servers  computing  empowers  organi¬ 
zations  to  re-engineer  business  processes,  to  distribute  transactions  to  streamline  operations, 
and  to  provide  better  and  newer  services  to  customers.”  [Turban,  1 995] 
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6.  Structural  Information  System  -  SSliS  Database 

The  concepts  of  Business  Process  Reengineering  (BPR)  and  Information  Systems  (IS)  can  be 
used  to  support  processes  associated  with  the  design,  construction  and  operation  of  a  vessel. 
The  purpose  of  using  BPR  and  IS  is  to  provide  an  information  process  flow  for  ship  owners, 
classification  societies  and  regulatory  authorities  to  implement  together,  and  thus  increase 
work  eflSciency  for  all  parties  across  aU  fijnctions  and  activities. 

Innovation  can  be  achieved  through  a  number  of  methods  used  to  manage  and  track  informa¬ 
tion  and  work  activities.  As  an  example,  consider  structural  inspection,  maintenance  and  re¬ 
pair  (IMR)  activities;  documentation  of  existing  information  flows  fi-om  the  initial  inspection 
to  shipyard  repairs  highlight  where  improvements  can  be  made.  Process  attributes  detail 
where  implementation  of  information  technology  (for  example,  inspection  recording  devices) 
and  organizational  changes  (empowerment  of  employees  to  make  decisions  on  behalf  of  all 
concerned  interests)  will  improve  ship  quality. 

It  is  assumed  that  the  changes  will  involve  cross-functional,  and  cross-organization  activities 
between  the  regulating  authorities,  classification  agencies,  and  the  ship  owners  and  operators. 
The  challenge  is  to  not  only  document,  but  also  detail  the  requirements  of  all  parties  within 
the  process  flow.  The  design  of  a  ship  structural  information  system  must  support  the  process 
flow  concept  to  be  of  practical  use. 

The  objective  of  this  report  is  take  the  format  for  reengineering  and  information  system  de¬ 
velopment  described  in  the  previous  chapters  and  apply  them  to  the  SSIIS  project.  To  illus¬ 
trate  the  potential  benefits  of  reengineering  during  information  system  design,  the  Structural 
Inspection,  Maintenance  and  Repair  (IMR)  process  has  been  detailed  in  suflBcient  detail  to 
enable  a  prototype  to  be  built.  TWs  prototype  is  used  to  demonstrate  how  the  integration  and 
customization  of  information  can  be  used  to  achieve  quality  improvements  associated  with  a 
ship’s  structural  system. 

6.1.  Maritime  Industry  Strategy 

As  identified  in  the  MSIP  study  the  fimdamental  goal  of  developing  an  information  system  is 
to  improve  the  quality  of  ship  systems  through  the  life-cycle  of  the  vessel.  This  includes  ad¬ 
dressing  structural,  equipment  and  operational  systems.  Establishment  of  measurable  objec¬ 
tives  along  with  the  development  of  an  information  system  provides  a  feedback  mechanism 
for  long-term  continuous  improvement, 

6.2.  Maritime  Industry  Obiactives 

For  the  mantime  industry  to  assess  and  inq)rove  its  performance,  measurable  objectives  must 
be  established.  If  the  goal  is  to  improve  the  quality  of  ship  systems,  then  a  initial  baseline 
must  be  established  upon  which  fiiture  assessments  can  be  measured.  The  measurable  otgec- 
tive  must  be  across  a  broad  spectrum  of  activities  which  will  be  difierent  for  agencies,  opera¬ 
tor/owners  and  shipyards. 

Usted  below  are  objectives  which  can  be  expanded  on,  after  detailed  consultation  with  the 
industry  sectors: 
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6.2.1.  U.S.  Coast  Guard 


The  Coast  Guard,  being  the  regulatory  arm  of  the  government,  sets  the  overaU  safety  re- 
quirements  for  the  industry.  Unsafe  practices  must  be  pre-empted  and  repilated  to  reduce 
risk.  Measurable  objectives  for  the  Coast  Guard  primarUy  include  a  reduction  m  mjuties  and 
loss  of  life  in  maritime  activities. 


6.2.2.  Classification  Societies 

Classification  Societies  being  commercial  entities  have  objectives  which  reflect  not  only  the 
requirements  of  the  Coast  Guard  but  also  the  internal  business  objectives  of  mamtainmg  and 
increasing  revenue  through  the  provision  of  services  to  the  shipping  commumty.  Examples  of 
measurable  objectives  for  classification  authorities  include: 

•  timely  incorporation  and  development  of  new  rules  and  regulations 

•  accurate  review  and  classification  of  planned  ships 

•  accurate  inspection  of  existing  ship  structures 

•  increased  services  to  ship  owners  offering  advice  on  new  technologies  and  safety 
requirements 


6.2.3.  Ship  Operators 

Ship  operators  are  responsible  for  maintaining  profit  margins  between  operating  expenses  and 
revenue  for  the  transport  for  cargo  and  obtain  maximize  operating  efficiency. 

Examples  of  measurable  objectives  for  ship  operators  include: 

•  reduced  ship  down-time 

•  reduced  ship  quafity  feilures  such  as  cracks  and  corrosion,  though  implementation 
of  effective  repair  programs  and  planned  maintenance  programs 

•  optimize  the  short  and  long  term  costs  through  effective  record  keeping  of  in¬ 
spection,  maintenance  and  repair  costs  and  operating  costs 


6.3.  SSIIS  Objectives 

The  development  of  an  industry  wide  SSIIS  project  must  encompass  the  objectives  of  all  of 
the  maritime  community  to  match  the  maritime  industry  strategy  of  improvmg  ship  qi^ty. 
The  incorporation  of  all  industry  processes  into  SSIIS  components  will  realize  nraximum 
benefit  for  all  industry  sectors.  The  goal  of  the  SSHS  project  is  to  show  that  all  objectives  can 
be  matched  with  the  development  of  an  industry  wide  information  system. 
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6.4.  SSIIS  -  Processes  and  Functions 

The  business  processes  associated  with  owning  a  ship  can  be  divided  into  two  categories: 

•  Design/Construction;  those  processes  associated  with  the  analysis,  design  and 
construction  of  a  new  vessel,  and 

•  Operations;  those  processes  associated  with  the  operation  of  the  vessel. 

Designing  and  building  a  ship  can  essentially  be  divided  into  two  processes.  The  analy¬ 
sis/design  process,  which  includes  the  specification  of  design  criteria  through  feasibility,  func¬ 
tional  and  detail  design.  The  fabrication  and  construction  process  includes  the  incorporation 
of  design  plans  and  specifications  into  the  production  of  the  structure. 

There  is  significant  overlap  between  these  two  processes  and  ideally  an  information  system 
would  incorporate  the  requirements  of  all  activities.  It  has  only  been  recently  that  such  sys¬ 
tems  have  been  proposed,  as  detaUed  in  Chapter  2,  with  the  current  NIDDESC  proposed  ISO 
standard  which  incorporates  design  and  construction  activities  within  the  development  of  an 
information  system. 

The  responsibility  of  operating  a  ship  can  be  divided  into  a  number  of  separate  processes  with 
some  overlap  in  certain  areas.  This  includes  cargo  management,  which  is  the  booking,  loading 
and  unloading  of  cargo.  Onboard  management,  including  storage  and  procurement  of  ship 
stores  and  crew  related  activities.  Finally,  mechanical  and  structural  inspection,  maintenance 
and  repair  activities. 

The  ship  operating  processes  are  detailed  in  Figure  6.1  shown  below.  These  processes  can  be 
expanded  out  to  include  specific  functions  and  activities  with  the  process.  This,  however,  has 
only  been  performed  for  the  Structural  IMR  process. 


Figure  6. 1  ;  Ship  Processes 

Within  the  SSIIS  2  project,  emphasis  has  been  given  to  ship  structural  systems,  hence  the 
main  focus  of  this  report  has  been  on  processes  associated  with  ship  structural  requirements. 


Overlap  between  structural  processes  such  as  the  Analysis®esi^Con^tion  and  the 
Structural  IMR  process  and  the  non-structural  processes  do  exist  and  have  been  highhghted. 

6.4.1.  Structural  IMR 

The  Structural  IMR  process  revolves  around  the  inspection,  maintenance  and  repair  of  the 
ships  structural  system.  This  includes  aU  potential  structural  quaUty  Mures  such  as  corrosion 
cracking  and  member/detail  overstressing.  It  includes  on-gomg  mamtenance  such  as  tank 
coating  and  anode  replacement  and  also  the  detailing  of  crack  repairs. 

The  structural  IMR  information  process  flow  is  detailed  in  Figure  6.2.  This  figure 

the  activities  associated  with  the  IMR  cycle,  both  as  functio^  performed  extemaUy  to  the 

information  system  and  as  activities  performed  by  the  information  system. 
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Figure  6.2  :  Structural  IMR  Information  Process  Flow 


The  fimctions  performed  externally  to  the  information  system  largely  information 

gathering  activities  or  physical  activities  performed  on  the  ship  structure.  The  nrformaion 
system  acts  as  the  management  tool  to  coordinate  the  functions  and  activities  perfonmd  on 
the  ship  structure.  The  system  enables  the  worker  to  perform  these  acUvities  in  an  efficient 
manner  by  manipulating,  collating  and  customizing  the  required  information. 
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The  functions  performed  externally  to  the  information  system  are  discussed,  including  the 
role  performed  by  the  information  system  in  the  Structural  IMR  process. 

6.4.1. 1.  Inspection  Planning 

Inspection  planning  forms  an  integral  component  to  improving  the  quality  of  ship  inspections. 
Planning  for  inspection  includes  the  selection  of  critical  ship  details  (CSD).  Those  details  that 
have  been  shown,  either  by  analysis  or  experience  be  those  with  the  highest  Mure  probabil¬ 
ity. 

The  Structural  IMR  process  assumes  the  ship  structure  has  already  been  entered  into  the  in¬ 
formation  system.  This  includes  a  foil  description  of  the  tanks,  frames,  bulkheads  and  details. 
Inspection  planning  utilizes  this  information  to  develop  a  plan  prior  to  the  inspection  to  en¬ 
sure  critical  areas  are  examined. 

The  puipose  of  planning  an  inspection  is  to  ensure  that  the  critical  areas  are  included  into  the 
iiKpection  pM  and  to  also  estimate  resources  and  time  required  for  the  inspection.  It  is  en¬ 
visaged  that  in  a  full  implementation  of  the  SSIIS  development  an  inspection  plan  is  devel¬ 
oped  tank  by  tank,  frame  by  frame  and  then  detail  by  detail.  This  generates  a  large  amount  of 
paperwork  for  the  inspector  to  handle  and  hence  inspection  recording  devices  should  be  in¬ 
corporated  to  coordinate  this  information.  One  of  the  benefits  of  IS  is  the  ability  to  customize 
the  presentation  of  information  for  the  user. 

The  infoiimtion  system  should  allow  the  user  to  generate  the  inspection  plan  based  on  differ¬ 
ent  inspection  techmques  and  conditions.  From  the  analysis  of  previous  inspection  results  for 
this  vessel  and  other  vessels  in  the  same  class. 

The  formation  system  should  allow  the  inspector  to  work  through  the  inspection  prior  to 
entering  the  tank  and  formulate  the  most  effective  and  efficient  technique  of  examining  the 
vessel  for  defects.  An  inspection  plan  is  advantageous  since  it  insures  that  critical  regions  re¬ 
ceive  attention.  The  inspection  plan  can  be  formulated  to  interface  with  technology  used 
during  the  inspection. 

Internal  to  the  information  system,  the  role  of  the  information  system  during  the  inspection 
planning  stage  is  to:  ^ 

•  maintain  a  record  of  critical  areas. 

•  provide  tools  to  analyze  previous  inspection  and  repair  records  for  location  of 
critical  areas,  which  will  facilitate  the  identification  of  new  trouble  areas. 

•  provide  the  means  to  plan  an  inspection,  using  information  supplied  by  the  user, 
for  example  inspection  techniques,  such  as  rafting  or  the  use  of  platforms. 

•  output  an  inspection  plan  for  use  during  the  inspection  as  a  means  to  record  in¬ 
spection  results 

6.4.1. 2.  Performing  the  Inspection 

During  the  inspection  a  list  of  defects  in  the  ship  structure  is  gathered,  this  includes  corrosion, 
cracking  and  other  quality  feilures.  Most  ship  operators  use  some  form  of  tracking  system  to 
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maintain  a  record  of  Mure.  However,  as  the  previous  SSIIS  report  determmed  there  are 

shortcomings  in  aU  methods  used  [Schulte-Strathaus,  1995].  This  includes 

tures  to  compare  within  classes  and  for  computerized  systems  the  lack  of  links  betwee 

graphical  and  textual  descriptions. 

Other  reports  [Holzmaii,  1992]  reviewed  methods  used  to  inspect  tankers  and  recommen^- 
te  tlTnlde  r^g  the  use  of  data  gathering  devices.  This  inchuW  vo.ce  re^^-on 
devices  or  personal  data  assistants  (PDAs).  The  inspection  pian  couid  be  downloaded  mto  the 
device  and  used  to  capture  inspection  resuhs  ‘on  the  fly’. 

Internal  to  the  information  system,  the  role  of  the  information  system  during  the  inspection 
su^e  is  to 

•  maintain  a  record  of  defects  found  during  inspection,  this  includes  detailed  infer- 
mation  associated  with  the  defect  such  as  location. 

•  provide  a  detailed  report,  quickly  and  easily  from  the  information  captured  durmg 
the  inspection. 

This  information  must  be  abie  to  be  easiiy  entered  into  the  information  system,  this  inclndes 
the  use  of  appropriate  technology  to  speed  the  input  of  information. 

6.4.I.3.  Planning  and  Designing  Repairs 

Once  defects  are  found,  the  IMR  cycle  moves  to  planning  and  designing  appropnate  repans 
The  repair  chosen  will  depend  on  a  number  of  factors  such  as,  remaining  vessel  operatic  a 

life  and  defect  location. 

This  decision  is  largely  taken  on  a  costAeneflt  analysis  mcorporating  short  “d 
costs.  The  choice  of  repair  technique,  flom  simple  re-weldmg  to  ^ 

impact  on  the  repair  costs.  Thus  the  operator  must  weigh  off  the  short-term  costs 

against  the  long-term  drawbacks  of  potential  further  work. 

Internal  to  the  information  system,  the  role  of  the  information  system  during  the  repair  plan- 
ning  stage  is  to 

•  update  the  inspection  findings  with  the  associated  repair 

•  offer  the  user  support  during  the  repair  design  phase  on  the  best  repair  technique 

•  provide  a  detailed  report,  quickly  and  easily  from  the  information  captured  durmg 
the  inspection  and  repair  process 

•  provide  a  means  to  the  shipyard  to  provide  a  cost  estimate  for  the  ship  repairs 

6.4.1. 4.  Performing  the  Repairs 

Repairs  to  the  ship  structure  must  be  carried  out  according  to  classification  society  and  Coast 
Guard  requirements.  Repair  information  must  be  entered  against  inspection  Mures  to  docu¬ 
ment  the  effectiveness  of  the  repair. 

Internal  to  the  information  system,  the  role  of  the  information  system  during  the  repair  stage 
is  to 
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•  provide  the  shipyard  with  information  on  repair  technique  and  associated  febrica- 
tion  procedures 

•  provide  a  means  for  the  shipyard  to  schedule  and  complete  the  work  efficiently 

6.4.2.  Analysis  /  Design 

The  Analysis/Design  process  traditionally  creates  different  computer  models  for  the  analysis 
and  then  the  design  of  a  ship  structure.  The  analysis  model  is  typically  used  to  ensure  accept¬ 
able  member  stresses  and  is  separate  to  the  design  drawings  commonly  produced  by  a  com¬ 
puter  aided  drawing  (CAD)  application.  The  ship  product  model  NIDDESC  ISO  standard  is 
an  attempt  to  enable  data  interchange  between  these  different  applications. 

To  folly  integrate  the  analysis  and  design  process  not  only  must  one  model  be  used,  but  other 
information  components  also  must  be  integrated  into  a  system.  This  includes  the  creation  of 
rule  databases  which  directly  interface  with  analysis  and  design  applications  and  the  creation 
of  design  specifications  which  act  as  templates  to  customize  rules  to  suit  vessel  specifications. 


6.4.2.1.  Rules 

Data  structxires  for  a  rule  database  must  be  formatted  to  interfoce  directly  with  data  entities 
and  fields  associated  with  the  ship  product  model.  This  will  require  linking  the  analysis  and 
design  ship  product  components  to  lists  of  rules  which  can  be  checked  for  compUance  as  the 
model  is  generated.  Individual  rules  within  the  database  can  be  linked  via  relationships  to  the 

originator  of  the  rule,  and  the  ship  product  model  field  where  the  rule  applies. 

6.4. 2. 2.  Design  Specification 

The  design  specification  details  the  functional  requirements  of  the  vessel,  this  information  is 
used  to  determine  the  appropriate  rules  upon  which  the  vessel  must  be  assessed.  This  includes 
not  only  design  information  but  also  inspection  and  class  requirements.  The  design  specifica¬ 
tion  ^o  acts  to  maintain  relationships  between  the  vessel  and  its  environmental  operating 
criteria.  It  should  be  recognized  that  the  specifications  may  change  as  the  ship  ages,  the  crite¬ 
ria  for  repair  may  be  different  than  those  for  design. 

6.4.2.3.  Plans  and  Arrangements 

The  structural  configuration  can  be  represented  by  a  number  of  methods;  the  traditional  two 
dimension  (2-D)  drawing  format,  which  the  introduction  of  computer  aided  drafting  has 
speeded,  or  the  newer  technology  of  ship  product  models  and  three  dimensional  (3-D)  mod¬ 
els.  3-D  models  can  be  represented  in  two  dimensions  through  the  definition  of  views. 

Information  syste^  developed  to  represent  the  ship  structures  must  be  flexible  enough  to 
emble  existing  ships  to  be  singly  generated  without  creating  fiiUy  detailed  product  models. 
Significant  investment  in  analyzing  existing  vessels  has  been  made.  Focus  must  be  made  to 

incorporate  data  structures  in  the  new  systems  that  can  be  uploaded  with  existing  analysis  and 
design  information. 
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$.4.2.4.  Analysis  .  •  i  a^c 

The  analysis  flmetion  acts  to  calculate  variables  rebted  to  the 

stresses  at  the  structural  detail  level  to  global  hydrodynamic  responds.  The  anal^is  toctron 
Ss  Ite  dba  to  the  ship  product  model  based  on  the  structural  armngement  of  tta  ve  - 
Ll.  The  analysis  results  can  then  be  check  against  the  design  specifications  and  rules  for  co  - 

rect  compliance. 

6.4.3.  Fabrication  /  Construction 

The  febrication  and  construction  process  involves  ^""ociated 

a  vessel  from  plans  and  specifications  to  tangible  reahty.  The  process  details  the  co«s^^t  o 

plan  from  cutting  the  steel  to  assembling  components  and  modules.  An 

and  construction  process  details  the  construction  sequence  to  improve  efficiency  and  qm  y 

of  construction.  It  details  fabrication  procedures,  incorporates  quahty  records  and  upd 

the  ship  model  created  during  the  analysis/design  process. 

6.4.4.  Mechanical  IMR 

The  mechanical  IMR  process  is  very  similar  to  the  structural  process,  however  the  mechani 
system  maintenance  is  an  ongoing  process  during  the  operation  of  the 
is  generally  performed  by  the  ships  crew  whereas  structural  mamtenance  ^ 

port  calls.^TTie  system  developed  by  Stolt  Nielson  is  an  example  of  a  mechamcal  IMR  proc¬ 
ess,  and  was  covered  in  Section  3.4.1 . 

6.4.6.  Cargo  Management 

Cargo  management  process  includes  the  loading  and  unloadh*  of  the  cargo,  and  m  a  My 
Sped  system  hi  provision  for  the  booking  of  cargoes.  This  sys^  ensu^  the  ship  b 
„rovS.2sed  during  loading,  cargoes  am  stored  in  the  correct  tanks  and  the  loadmg  and 
discharge  operations  performed  in  an  safe  manner. 

6.4.6.  On-Board  Management 

On-board  management  includes  the  management  of  crew  operations  to  onboard  logistics  md 
^^opeSl  sybems.  Integrated  systems  for  the  vessel  control  altow 
and  engine  information  to  be  presented  in  the  bridge.  Recent  advances  have  included  the  de- 
vebpnfent  of  ship  monitoring  systems  to  give  real-time  displays  of  vessel  structural  stresses 
along  with  vessel  routing  systems  to  aid  reduction  of  ship  fetigue. 


7.  Prototype  Description 

The  SSIIS  prototype  is  a  Microsoft  (MS)  Access  v2.0  database.  Access  is  a  MS  ^Vlndows 
application.  To  run  the  prototype,  both  MS  Windows  and  Access  must  be  installed  on  a  IBM 
compatible  PC.  It  is  suggested  a  minimum  hardware  configuration  of  a  486  machine  with  at 
least  8M  of  RAM  is  used.  Installation  instructions  are  on  the  disk  supplied  with  the  report. 

The  SSIIS  prototype  focuses  on  the  Structural  Inspection  Maintenance  and  Repair  (IMR) 
process  as  shown  in  Figure  6.2.  However,  the  Structural  IMR  process  requires  information 
fi'om  other  processes.  Data  generated  in  other  processes  is  utilized  by  the  Structural  IMR 
process.  As  an  example,  the  ships  configuration  or  design  information  must  be  entered  to  lo¬ 
cate  where  the  failures  are  found  during  the  inspection. 

Thus  the  information  requirements  of  the  Structural  IMR  process  can  be  detailed  on  three 
consecutively  detailed  levels  to  determine  the  information  relationships.  This  consists  of  the 

•  Process/Process  Relationship:  At  this  level,  information  relationships  between 
processes  are  highlighted. 

•  Function/Function  Relationship:  Once  the  processes  are  broken  down  into  their 
individual  functions,  the  relationships  between  fiinctions  can  be  determined. 

•  Function/Entity  Relationship:  This  is  the  detailed  level  where  the  relationship 
between  the  functions  and  individual  data  entities  within  the  function  are  shown. 
The  data  entities  are  further  broken  down  into  data  fields,  however  to  represent 
where  individual  fields  are  modified  is  too  detailed  for  the  matrix  notation. 

7.1.  Data  Structure 

The  data  structmes  developed  must  be  flexible  enough  to  handle  the  introduction  of  new 
^ctions  as  the  information  system  matures.  A  relational  database  structure  is  ideal  for  ensur¬ 
ing  future  flexibility. 

7.1.1.  Process/Process  Relationships 

Process/Process  relationships  highlight  where  information  created  within  one  process  is  read, 
updated  and/or  deleted  within  another  process.  This  is  shown  in  Figure  7.1  for  the  ship  own¬ 
ing  processes  previously  detailed. 

For  exampte  the  Structural  IMR  process  reads  and  updates  information  created  by  the 
Analysis/Design  Process  and  the  Fabrication/Construction  process.  This  highlights  that  data 
structures  must  be  developed  for  compatibility  between  Analysis/Design  functions  and  the 
Structural  IMR  functions. 

One  of  the  objectives  is  to  ensure  that  the  information  system  is  life-cycle  focused,  such  an 
approach  to  data  structures  will  also  ensure  that  data  integrity  is  maintained  by  the  system. 
This  is  important  as  future  modules  are  implemented  so  that  information  is  not  duplicated  and 
the  system  acts  as  a  central  repository  for  all  data. 
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Figure  7.1  :  Process  /  Process  Relationships 
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where  information  is  created  by  a  process. 

where  information  is  read  and  used  by  a  process  but  has  been  previously  cre¬ 
ated  by  another  process, 
where  existing  information  is  updated. 


7.1.2.  Funotion/Function  Relationships 

The  fimction/fimction  relationship  breaks  down  the  information  dependence  further.  This 
again  lughlights  at  a  more  detailed  level  where  information  originates  and/or  is  used.  An  ex¬ 
ample  is  given  in  Figure  7.2. 
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Figure  7.2  :  Function  /  Function  Relationships 


7.1.3.  Function/Entity  Relationships 

The  final  step  is  to  detail  the  fimaions  into  entities  or 

tionship  between  the  functions  and  entities  is  presented  m  Figure  7.3.  With  the  SSIIS  pro 
type,  the  entities  represent  a  relational  table  with  which  the  IMR  functions  read  and  upd 
info^tion.  The  relational  tables  are  detailed  in  Appendix  A. 
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Figure  7.3  ;  Structural  Function  /  Entity  Relationship 

Onlv  the  required  in  the  Structural  IMR  process  have  been  included  in  the  SSIIS 

prototype.  In  futureVelopments  of  SSIIS  the  entities  required  for  all  functions  and  proc- 

esses  can  be  included  in  such  a  format. 


The  data  entities  for  the  Structural  IMR  and  the  Analysis/Design  process  are  shown  in  Figure 
7.4.  This  demonstrates  how  processes  can  be  dependent  on  other  processes  for  the  creation 
of  information.  The  Structural  IMR  process  is  reliant  upon  the  vessel  description  created  in 
the  Analysis/Design  process.  Failures  and  other  defects  must  have  a  recorded  position  to  gain 

maximum  benefit  for  the  integration  of  information  into  a  process-orientated  information 
system. 
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Figure  7.4  :  Data  Entities  for  Structural  Processes 


7.2.  Tables 

M  the  prototype  is  interided  to  demonstrate  the  appUcation  of  an  information  system,  the 
Mta  requirements  maintained  in  the  database  have  been  kept  to  a  minimum.  Comprehensive 
data  structures  have  not  been  developed  and  the  focus  of  the  prototype  has  been  on  the  in¬ 
formation  associated  with  the  Structural  IMR  process.  The  data  structures  for  the  prototype 
are  given  in  Appendix  A. 

^e  data  structures  have  been  developed  to  demonstrate  a  working  version  of  a  Structural 
IMR  system  and  thus  shortcomings  are  evident.  It  is  anticipated  that  future  development  will 
detail  the  system  fiirther  through  feedback  and  comment  from  industry  groups. 

7.3.  Forms 

Once  the  SSIIS  prototype  is  loaded,  the  opening  screen  as  shown  in  Figure  A.I.  is  presented 

to  the  user.  At  present,  there  are  a  selection  of  four  further  entry  screens  available  to  the  user 
these  are  ’ 

•  P^sel  Form:  This  series  of  forms  to  enables  the  user  to  enter  vessel  configura¬ 
tions.  The  information  fields  that  can  be  entered  fi-om  this  form  and  the  associated 
subforms  represents  the  structural  configuration  of  the  vessel.  This  includes  de¬ 
tails  pertaining  to  tanks,  fi’ames  and  details.  See  Figures  A.2-A.8. 
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.  T»iinPction  Form:  This  series  of  forms  aUows  the  user  to  enter  vessel  mspection 
information,  including  details  planned  for  inspection,  and  also  mspection  and  re¬ 
pair  results.  See  Figures  A.9-A.12. 

.  This  form  allows  the  user  to  enter  companies  that  can  he  used  later 

for  entries  in  the  Vessels  and  Inspection  forms.  See  Figure  A.13. 

•  Personnel.  This  is  to  aUow  the  user  to  enter  individuals  who  may  be  performmg 
work  on  the  vessel.  See  Figure  A.14. 

Thf»  Vpwel  Form  allows  the  user  to  input  the  vessel  arrangement  and  plans.  Foi^new  bu’ d 
Centered  as  part^f  the 

ships  a  simple  format  must  be  available  for  operators  to  qmekly  enter  the  ship  configuration 
to  take  advantage  of  other  SSIIS  processes  and  functions. 

At  ntpisent  the  SSIIS  prototype  uses  scanned  images  to  represent  views  and  details,  a  future 
^op^nfwuSSs  to  CAD  drawings.  However  the  product  model  concept  of- 
S“rm  solution  to  linking  graphicai  and  textud  hdb.™t.on.  The  NID- 
DESC/STEP  appLtion  protocols  for  a  ship  product  model  is  detailed  m  Section  3.3. 

Within  the  Vessel  Form  the  user  can  input  ship  information  in  a  number  of  categories  entered 
in  via  the  following  subforms 

.  General-  This  tabbed  form  allows  the  user  to  enter  ship  specific  iirfonmtion  relat¬ 
ing  to  the  classification  society.  In  the  construction  of  a  fiiUy  developed  ^plemen- 
S  of  an  information  system,  this  section  would  be  expanded  to  mclude  a  ex¬ 
panded  range  of  ship  details.  See  Figure  A.2. 

•  GA-  The  form  shows  the  vessel  general  arrangement,  this  ^ow  the  to  °btam 
an  orientation  of  the  vessel  with  respect  to  the  tank  numbers  and  positions.  See 

Figure  A.3, 

.  ImD  Schd-  This  fom  allow  the  user  to  examine  the  last  and  next  scheduled  in- 
S  due  to  both  the  classification  society  and  Coast  guard.  The  next  owner 
scheduled  inspection  can  also  be  entered.  See  Figure  A.4. 

•  Tanks:  allows  the  user  to  enter  tank  specific  information.  At  this  stage  of  the 
SSIIS  development,  the  data  requirements  are  limited  to  those  reqime 

quality  failures.  In  a  full  implementation,  this  would  include  information  to  be  able 

to  handle  stability  effects.  See  Figure  A.5. 

.  Frames:  The  frames  table  is  intended  to  allow  the  user  to  represent  the  ^ansv^se 
and  longitudinal  divisions  within  a  ship  structure.  For  this  example  transverse  we 
frames  have  been  included.  See  Figure  A.6. 

•  Bulkheads:  It  is  intended  in  the  prototype  system  that  the  vessel  tanks  be  entered 
as  a  collection  of  bulkheads.  See  Figure  A.  7. 

•  Details:  The  details  table  allows  the  user  to  enter  structural  details  associated  with 
the  ship  structure.  It  is  intended  to  provide  a  level  of  detad  such  that  ^  mspection 
can  locate  physical  defects  at  a  location  within  the  detaU.  See  Figure  A.8. 


The  Inspection  Form  allows  the  user  to  input  inspection  and  repair  information.  The  entry 
boxes  on  Aese  foi^  uses  information  entered  from  the  Vessel  Form.  Within  the  user  can 
input  ship  information  in  a  number  of  categories  entered  via  the  following  subforms 

•  General:  Non-specific  information  can  be  entered  here  relating  to  a  description  of 
the  ptaed  inspection,  maintenance  of  repair  activities.  People  associated  with 
the  activities  and  Reports  produced  as  a  result  of  the  work.  See  Figure  A.9. 

•  CAIP  Details:  Critical  areas  within  the  ships  structure  can  be  identified  here.  See 
Figure  A.  10. 

•  Tank  Coatings:  Maintenance  to  tank  coatings  can  be  entered  within  this  subform. 
See  Figure  A.11. 

•  Cracks/Corrosion:  Quality  Mures  identified  during  an  inspection  can  be  entered 
into  the  database  via  this  form.  See  Figure  A.  1 2. 

7.4.  Reports 

At  present,  the  outline  for  three  reports  has  been  programmed  into  the  prototype.  They  are 

accessed  via  the  Report  Selection  Form,  see  Figure  A.  15.  The  following  reports  can  be  ac¬ 
cessed; 

•  Vessel:  The  vessel  configuration  can  be  output,  this  includes  tanks,  frames,  bulk¬ 
heads  and  details.  An  example  Vessel  Report  from  the  SSIIS  prototype  is  given  in 
Appendix  B. 

•  Inspection:  Inspection  information  can  be  output,  this  includes  failure  locations 

•  CAIP  Report:  An  example  CAIP  report  can  be  printed  based  on  the  information 
contained  in  the  information  system.  This  is  based  on  the  requirements  outline  in 
the  SSIIS  report.  [Schulte-Strathaus,  1995].  An  example  CAIP  Report  from  the 
SSIIS  prototype  is  given  in  Appendix  C. 
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8.  Future  Development 


The  foture  development  of  the  SSIIS  prototype  will  continue  the  evolution  of  engineering 
solutions  for  optimizing  the  maintenance  and  operation  of  existing  ships.  The  SSIIS  as  a  re¬ 
search  development  project  should  continue  to  focus  on  the  Structural  Inspection,  Mainte¬ 
nance  and  Repak  (IMR)  Process.  Areas  of  interface  with  other  ship  owning  processes  must 
be  identified  to  incorporate  the  information  links  in  a  larger  commercial  development. 

Future  work  on  the  SSIIS  project  should  focus  on  the  following  areas: 

•  Reqimements  ^alysis  of  both  management  and  the  end  users  of  SSIIS.  This  will 
identify  and  prioritize  system  requirements  of  all  participants  (USCG,  classifica¬ 
tion  societies  and  owner/operators)  in  the  structural  IMR  process. 

•  Continue  development  of  the  data  structure  used  to  represent  the  ship  structure 
for  all  components  of  the  IMR  process.  The  NIDDESC/STEP  application  proto¬ 
cols  provide  a  starting  point  for  fixture  development  [NIDDESC,  1993] 

•  Implement  an  inspection  planning  system  to  analyze  failure  trends  and  allow  the 
ship  inspector  to  interactively  plan  inspections  to  cover  critical  areas. 

•  Interface  the  inspection  plan  with  the  collection  and  storage  of  inspection  results. 

•  Implement  a  repair  decision  support  system  interfeced  to  the  defects  recorded 
during  an  inspection.  The  Repair  Management  System  (RMS)  provides  a  starting 
point  for  this  development.  [Ma,  Bea,  1995] 

•  Demonstrate  the  practicality  of  the  SSIIS  development  and  enhancements  of  the 
structural  IMR  process  module  through  application  to  an  example  tank  ship. 

•  Develop  an  implementation  plan  for  commercial  development  once  the  practicality 
of  the  system  has  been  proven. 

Reengineering  of  ship  processes,  as  introduced  in  this  report,  is  essential  to  gain  maximum 
a  vantage  fi-om  the  introduction  of  information  technology.  Reengineering  the  structural  IMR 
process  has  the  following  goals: 

•  Iinproved  structural  quality,  through  the  identification,  inspection  and  repair  of 
critical  areas. 

•  Building  of  tacit  knowledge,  through  the  ‘storage’  and  ‘retrieval’  of  inspection 
and  repair  techniques. 

•  Increased  accuracy  of  information  exchange,  extraction  of  trends  and  forecasting 
of  future  developments. 

The  fully  developed  SSIIS  will  be  capable  of  being  accessed  and  utilized  by  own- 
er^operators,  builders/repairers,  regulators  and  classification  societies.  Intense  cooperation 
c^oTTo  between  these  industry  sectors  to  match  different  objectives.  With  any  future 

SSIIS  development,  focus  on  reducing  the  barriers  to  organizational  change  will  foster  a 
reengmeered  system  that  can  effectively  be  utilized  by  the  industry. 


53 


I 


The  following  recommendations  are  intended  to  be  mcorporated  into  the 
T  w  Zcess  description  detaUed  in  Chapter  6.  The  long  term  development  of  the  SSIIS 
project  would  be  on  a  cUent/server  hardware  and  software  system,  the  specification  of  such 
system  will  depend  on  future  project  requirements. 

8.1 .1 .  Requirements  Analysis  and  Benchmarking 

The  structural  IMR  process  identified  in  Figure  6.2  must  be  enumerated  and  end  users  of  the 
So^Srsystem  iLtified.  These  potential  users  of  the  information  systern  must  be  mte  - 
“o  .he  propose,  reengmeered  process  ,o  ..«m  in  order  ,o  0^“^ 

and  identify  required  features,  i.e.  system  requirements.  Management  must  also  be  ^nsulted 
r^dter^e  Eheir  requirements  and  project  objectives.  These  requirements  must  be  pnon- 

tized  to  match  the  project  objectives  and  ensure  the  efficient  development  of  sue  asyse  . 

Performing  the  requirements  analysis  will  result  in  an  easier  implementation  of  a  fiitiOT  com- 
^iTTvetp^”  The  effiirt  of  including  the  end  users  wiU  result  in  a  systm  to  which 
te  ^rs  fel  *“lve  contributed  .  nie  resulting  ‘ownership’  of  tte  system  by  the  i^ 
wffl  encourage  acceptance  and  contributions  for  fiirther  refinements.  The  setting  up  of  a  pilot 
™T^monsLe  the  practicality  of  SSIIS  is  important  to  introduce  users  to  new  tech- 

nology  and  to  gain  assent  of  required  organization  changes. 

A  comprehensive  benchmarking  review  of  inspection  techniques 

shipping  industry  and  then  outside  industry  would  be  useful  to  determme  best  practice 
techniques  that  could  be  incorporated  into  a  SSIIS  development. 

8.1.2.  Data  Structure 

Overall  the  data  structure  used  to  represent  the  structural  arrangement  of  the  vessel  must  be 
Ttfp  developed  during  Phase  II  of  ri«  SSIIS  project  only  n^d  sc^d 

^I  lo  represent  graphical  information.  The  incorporation  of  the  ship 
deWtions  introduced  in  Ltion  3.3.1  [NIDDESC,  1993]  was  beyond  the  scope  of  this  proj- 

6Ct. 

Incorporation  of  a  product  model  definition  may  not  be  required  until  the  commerci^  devel¬ 
opment  of  the  SSIIS  concept  given  the  extensive  detail  that  must  be  programme  .  oweve 
for  future  research  projects  the  existing  methodology  used  in  the  SSIIS  protot>^  for  entty  o 
graphical  information  and  broad  textual  descriptions  of  the  ship  structure  must  be  extended. 

8.1.3.  Inspection  Planning 

The  inspection  planning  module  can  be  improved  through  the  inclusion  of  a  Mure  trend 
analysis  component  and  a  system  for  planning  repairs. 

The  analysis  of  Mure  trends  and  the  location  of  critical  details 

manual  system  used  to  identify  critical  areas.  At  present  cntical  areas  ^e  identified  by  experi 
ence  often  after  the  failure  of  hundreds  of  structural  details.  M  analps  component  would 
have  a  dual  role,  to  identify  critical  areas  and  to  track  and  identify  repair  efiectivenes  . 

Enabling  SSIIS  to  plan  the  route  of  an  inspection  survey  prior  to  entemg  the  tank  will  have 
signified  benefits.  This  component  would  consider  the  methods  used  to  gam  access  inside 


the  ship  structure  and  build  a  knowledge  base  of  how  inspectors  conduct  surveys.  This  allows 
the  tacit  knowledge  developed  through  years  of  field  work  to  be  codified  and  used  by  less 
expenenced  inspectors  to  plan  their  inspections. 

8.1.4.  Inspection  Activities 

Work  IS  required  to  interfece  the  inspection  plan  (complete  with  critical  areas)  and  the  record- 
mg  of  i^pection  results.  This  will  ensure  critical  areas  are  inspected  and  results  accurately 
recorded.  A  discussion  of  interfacing  technology  and  humans  during  inspection  is  detailed  in 
Section  6.4.2.  Research  work  in  this  area  is  currently  being  conducted  by  the  U.S.  Coast 


8.1.5.  Repair  Planning 

The  repair  planning  component  of  SSIIS  should  incorporate  findings  fi-om  the  Repair  Man- 

developed  for  critical  details  during  the  Ship  Maintenance  Project 

guidelines  can  be  incorporated  into  the 
SSllS  development  to  give  advice  to  engineers  on  how  best  to  repair  fractures  and  renew  ex¬ 
cessively  corroded  elements  and  plate. 

T^e  RMS  provides  a  basis  for  a  simplified  repair  analysis  of  critical  details.  This  repair  analy¬ 
sis  n^es  use  of  the  time  to  the  observed  cracking  to  define  the  long-term  cyclic  loadings  re¬ 
quired  to  produce  the  observed  fracture.  The  analysis  also  makes  use  of  stress  reduction  fac¬ 
ers  to  define  the  effects  of  different  repair  alternatives  in  reducing  (or  increasing)  cracking 
^riot  spotj  stresses. 

The  system  allows  a  fest  estimate  of  the  expected  fatigue  Hves  associated  with  alternative  re¬ 
pair  strategies.  This  information  combined  with  cost  estimates  for  each  of  the  repair  strategies 
can  then  be  used  to  make  cost-life  trade-off  evaluations  to  define  the  repair  that  should  be 
implemented  for  a  particular  class  of  critical  ship  detail. 

8.1.6.  Testing  and  Implementation 

The  ^acticaHty  of  the  SSIIS  development  can  be  demonstrated  though  a  pilot  program  using 
data  from  an  existmg  vessel.  The  entire  vessel  need  not  be  entered  but  a  representative  por¬ 
tion,  (such  as  several  tanks)  are  required.  Choosing  only  a  representative  segment  of  the  ves- 
se  and  demonstrating  several  of  the  above  future  developments  will  ensure  a  clear  set  of  re- 
Quirements  with  which  to  continue  development. 

Once  the  SSIIS  prototype  is  proven,  commercial  development  can  commence.  A  phased 
testmg  and  implementation  program  can  be  designed  to  ensure  industry  acceptance  of  the 
^  performed  by  starting  with  a  committed  owner/operator  who  can 

and  serve  as  the  testing  ground  prior  to 

Benefits  Of  the  system  can  be  demonstrated  against  the  baseline  measurable  objectives  de- 
tenmned  prior  to  project  implementation.  These  measurable  objectives  must  be  identified  by 
the  mdustry,  for  example,  out  of  service  time  and  yearly  repair  costs,  see  Section  6  2 
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9.  Conclusions 

developed  the  basic  framework  for  the  information  system  to  support  the  Struc¬ 
tural  IMR  process.  The  Stmctural  IMR  process  includes  the  foUowing  functions,  Inspection 
Activities,  Repair  Planning  and  Repair  Activities.  These  functions  share 
and  build  on  common  data  to  complete  individual  activities  within  the  function. 

The  role  of  the  information  system  is  to  ensure  that  data  is  transferred  between  the  functions 
^d  activities  m  an  efficient  manner.  Reengineering  and  information  system  design  principles 

have  been  used  to  generate  the  interactions  and  the  information  flow  for  the  Structural  IMR 
process. 

The  SSIIS  protop^ie  represents  the  start  of  an  information  system  to  fulfill  the  requirements 
of  a  comprehensive  Structural  Inspection,  Maintenance  and  Repair  System.  At  present,  only 
the  structme  and  future  direction  of  the  system  has  been  detaUed.  Work  is  required  to  further 
develop  the  system  to  fully  yield  the  benefits  of  an  integrated  information  system. 

Further  development  of  the  SSIIS  prototype  would  result  in  improved  vessel  quality  through 

•  improved  inspection  planning,  through  analysis  of  existing  failure  trends  and  the 

utilization  of  the  information  system  to  customize  and  detail  the  individual  tank  in¬ 
spections. 

•  improved  recording  and  reporting  of  vessel  inspections  and  the  central  archiving 

of  vessel  feilure  records.  ® 

•  improved  repairs,  using  a  decision  support  system  the  information  system  can  be 

used  to  determme  the  best  repair  for  a  given  Mure  based  on  a  number  of  input 
factors.  ^ 

The  SSIIS  protore  is  used  to  demonstrate  the  appUcation  of  information  technology  in  the 
n^gement  of  ship  stmctures.  The  emphasis  within  this  project  has  been  on  operational  as- 
^ts  associated  with  the  inspection  maintenance  and  repair  of  ship  structural  systems  and  it 
IS  noM  that  scope  exists  to  expand  the  project  to  include  other  processes.  There  is  signifi- 
^a^ady™^”^  software  addressing  many  of  these  other  processes  available  to  the  indus- 

The  mantime  industry  must  continue  to  develop  software  and  systems  used  to  design  and  op¬ 
erate  vessels.  A  focus  ship  processes  ensures  systems  are  developed  to  integrate  informa- 
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Figure  A.2  :  Form  Vessels,  Subform  General 
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GA  Drawing 

Relation  to  Database  Vessel 

DrawingsA^iews 

Table  A.1  :  Data  Entities  for  Database  Vessels 
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Figure  A.4  :  Form  Vessels,  Subform  Inspection  Schedule 
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Inspection  Schedule  ID  Counter 
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Table  A.2  ;  Data  Entities  for  Database  Vessels  Inspection  Schedule 


A.4 


'■>  ,.,..1:^.: _ f _ _„_£:-':^l- :.'  a  -'^V'. •';; ;~7^'  ■''''■ -’-l  . 


'■•  Tank*;  . 

--•: '  -'vW' 

■j.l 

k\v ': 

III 

1 

iiiSI^PSpISf 

IForwanrihi^ 

Taidctype 

:  0ap«i^ 

Tankcoatfitg 

4'  '}'•■■' 

1P 

Port 

|OT  Frame  1 

loT  Frame  4 

Cargo 

1 

L 

Inorganic  Zinc 

.  -  :'-V 

1C 

Centre 

lOT  Frame  1 

PT  Frame  4 

Cargo 

_L 

1 

Inorganic  Zinc 

IS 

Starboard 

iOT  Frame  1 

OT  Frame  4 

Cargo 

J_ 

_ h 

Inorganic  Zinc 

:  s 

2P 

Port 

.V:,V 

<->/  V'  - 

Cargo 

J_ 

1 

a 

inorganic  Zinc 

.  C;' 

2C 

Centre 

1 

‘'* 

Cargo 

i_ 

1 

Inorganic  Zinc 

2S 

-j— 

Starboard 

. ...Ezzrz: 

jp  X.  5'^  ,  / 

f— - - T  V,~»:ii..a  . 

Figure  A.5  :  Form  Vessels,  Subform  Vessel  Tanks 
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Frames 
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Table  A.  3  :  Data  Entities  for  Database  Vessels 
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Figure  A.6  :  Form  Vessels,  Subform  Frames 
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Figure  A.7  :  Form  Vessels,  Subform  Bulkheads 
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Relation  to  Database  Vessel 
DrawingsA/^iews 


Comments 


Table  A.5  ;  Data  Entities  for  Database  Vessel  Bulkheads 


A.7 


y  .ci;V> ‘I  -«*,  II  I  III- iiiiiiiittiMwaliirtWMWtT^^ 


:m  .  'mm  , 

Frame 

O'  . 

Detail  1 

IP  1 

IP  Forward Tra 

t:;V; . . 

Side  Shell  Longitudinals  j 

OT  Frame  l 

Detail  2 

IP 

IP  Forward  Tra 

.  i;  '■  ^r.v:Vi  ■.i,..',...,^ 

Bottom  Longitudinals 

OT  Frame  1 

{Ul 

Detail  3 

1P 

IP  Longitudinal 

Longitudinal  Bulkhead  Lower  Strake 

11 

OT  Frame  1 

C 

"  '}0'^  ; 

CAIP  Detail  1 

L__:^ — 

c 

1  SN  ---a" 

Transverse  Web 

Fr 

— 

CAIP  Detail  2 

v::.4 "T^ 

T,, _  \ar^iu 

E 

■  .^.  ..vv;- 

y.  -V 

V',:  '<-•=■' 


Figure  A.8  ;  Form  Vessels,  Subform  Details 


Field 

Format  of  Field  or  Relation 

Comments 

Detail  ID 

Detail  Name 

Vessel  Reference 

Tank  Reference 

Bulkhead  Reference 

Frame  Reference 
Drawing  Reference 

Structural  Detail  Type 
Reference 

Coimter 

Text 

Relation  to  Database  Vessels 

Relation  to  Database  Vessel  Tanks 
Relation  to  Database  Vessel  Bulk¬ 
heads 

Relation  to  Database  Vessel  Frames 
Relation  to  Database  Vessel  Draw- 
ingsA^iews 

Relation  to  List  of  Detail  Types 

References  type  of  detail  according  to 
ABS  Specification 

Table  A.6  :  Data  Entities  for  Database  Vessel  Details 
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Figure  A.9  :  Form  Inspections,  Subform  Inspection  Description,  Subform  Inspection  Person¬ 
nel,  Subform  Inspection  Reports 


Field 

Format  of  Field  or  Relation 

Comments 

Inspection  Description  ID 
Inspection  Reference 

Inspection  Description 

Inspection  Personnel  ID 
Inspection  Personnel 

Inspection  Reference 

Inspection  Report  ID 

Inspection  Reference 

Inspection  Report  Company 
Inspection  Report  Title 

Inspeaion  Report  Doc  Num 
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Relation  to  Database  Inspections 
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Relation  to  List  of  Personnel 
Relation  to  Database  Inspections 
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Relation  to  Database  Inspections 
Relation  to  List  of  Companies 
Text 

Text 

Table  A.7:  Data  Entities  for  Database  Inspection  Description,  Personnel  &  Reports 
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Figure  A.l  1  :  Form  Inspections,  Subform  Inspection  IMR  Tank 


Inspection  Tank  Id 
Inspection  Reference 
Tank  Reference 

Bulkhead  Reference 

From  Frame 

To  Frame 


Memo 


Format  of  Field  or  Relation 


Counter 

Relation  to  Database  Inspections 
Relation  to  Database  Vessel 
Tanks 

Relation  to  Database  Vessel 
Bulkheads 

Relation  to  Database  Vessel 
Frames 

Relation  to  Database  Vessel 
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Comments 


Table  A.9  :  Data  Entities  for  Database  Inspection  IMR  Tanks 
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Figure  A.12  ;  Form  Inspection,  Subform  Inspection  IMR  DetaUs 


Field 

Format  of  Field  or  Relation 

Comments 

Inspection  Failure  Id 

Coimter 

Inspection  Reference 

Relation  to  Database  Inspections 

Inspection  Method 

Inspector 

Tank  Reference 

Text 

Relation  to  List  of  Personnel 

Relation  to  Database  Vessel  Tanks 

Bulkhead  Reference 

Relation  to  Database  Vessel  Bulk¬ 
heads 

Frame  Reference 

Relation  to  Database  Vessel  Frames 

Detail  Reference 

Relation  to  Database  Vessel  Details 

Failure  Type 

Text 

Length/Area 

Nmnber 

Cause 

Text 

Planned  Inspection 

Yes/No 

Repair  Status 

Repair  Reference 

Text 

Relation  to  Database  Vessel  Draw- 
ingA^iew 

Memo 

Memo 

Table  A.10  :  Data  Entities  for  Database  Inspection  IMR  Failures 


Figure  A.13  :  Form  Companies 


Field 

Format  of  Field  or  Relation 

Company  ID 

Counter 

Full  Name 

Text 

Full  Name 

Text 

Short  Name 

Text 

Street 

Text 

City 

Text 

State 

Text 

Zip 

Text 

Country 

Text 

Company  Type 

Text 

Memo 

Comments 
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Table  A.  1 1  :  Data  Entities  for  List  of  Companies 


Field 


Format  of  Field  or  Relation 


Comments 


Personnel  ID 

Counter 

Surname 

Text 

First  Name 

Company  Reference 

Text 

Relation  to  “List  of  Companies” 

Position 

Text 

Years  Experience 

Number 

Memo 
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Table  A.12  :  Data  Entities  for  List  of  Personnel 
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Figure  A.  15  :  Form  Report  Selection 


A.15 


Appendix  B :  Vessel  Report 

Vessel  Report 


The  Oil  Tanker 


Class:  70KDWT 
Owner:  Best  Ship 

Best  Ship  Company 

6543  Dockyard  Ave 
Riverfront  CA  94722 
USA 

Operator:  Oil  A. 

Oil  Abroad 

123  Murky  Waters 
Downtown  CA  94720 
USA 


Classification  CS 

Class.  Society 

954  Uptown  St. 
Ritzburg  CA  94721 
USA 


CS  id:  34232 
USCG  id:  2323 


Shipyard:  Jolly  Ship  Building 
Delivery:  1/7/77 
Hull  Number:  232 
DWT:  40000 


B.l 


General  Arrangement 


The  Oil  Tanker 


Tanks 


M 

Tank  Name  Tank  Location  CaDaeitv 

Aft  Frame 

Fwd  Frame 

Tankcoatino 

Ballast 

33 

3P 

Port 

1 

Epoxy 

35 

3S 

Starboard 

1 

Epoxy 

45 

5P 

Port 

1 

Epoxy 

47 

5S 

Starboard 

1 

Epoxy 

Ballast  Caoacitv: 

4 

Camo 

28 

1C 

Centre 

1 

OT  Frame  4 

OT  Frame  1 

Inorganic  Zinc 

27 

IP 

Port 

1 

OT  Frame  4 

OT  Frame  1 

Inorganic  Zinc 

29 

IS 

Starboard 

1 

OT  Frame  4 

OT  Frame  1 

Inorganic  Zinc 

31 

2C 

Centre 

1 

Inorganic  Zinc 

30 

2P 

Port 

1 

Inorganic  Zinc 

32 

2S 

Starboard 

1 

Inorganic  Zinc 

34 

3C 

Centre 

1 

inorganic  Zinc 

43 

4C 

Centre 

1 

inorganic  Zinc 

42 

4P 

Port 

1 

Inorganic  Zinc 

44 

4S 

Starboard 

1 

Inorganic  Zinc 

46 

5C 

Centre 

1 

Epoxy 

Carao  Caoacitv: 

11 

The  Oil  Tanker  _ _ 

Frames 

M 

Name  '± 

Tank 

Drawing: 

32 

Centreline  Gird 

0 

31 

Swash  Bulkhea 

0 

30 

Oil  Tight  Buikh 

0 

29 

Transverse  We 

0 

19 

OT  Frame  1 

1  IP 

20 

OT  Frame  2 

2  1C 

21 

OT  Frame  3 

3  IS 

22 

OT  Frame  4 

4 

23 

OT  Frame  5 

5 

24 

OT  Frame  6 

6 

25 

OT  Frame  7 

7 

26 

OT  Frame  8 

8 

OT  Frame  9 

9 

28 

OT  Frame  10 

10 
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The  Oil  Tanker 


Bulkheads 

Tank  jd 

Name 

Type 

Frame 

Drawina: 

12 

Horizontal  Webs  at  OT  Bulkhea 

11 

number  1 1 

1P 

IP  Aft  Transverse  Bulkhead 
Transverse 

OT  Frame  4 

4 

IP  Side  Shell 
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*^2 

IP  Longitudinal  Bulkhead 
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2 
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Appendix  C  :  CAIP  Report 

CAIP  Report 

The  Oil  Tanker 


Class:  70KDWT 
Owner:  Best  Ship 

Best  Ship  Company 

6543  Dockyard  Ave 
Riverfront  CA  94722 
USA 

Operator:  Oil  A. 

Oil  Abroad 

123  Murky  Waters 
Downtown  CA  94720 
USA 


Classification  CS 

Society:  Class.  Society 

954  Uptown  St. 
Ritzburg  CA  94721 
USA 


CS  id: 

34232 

USC6  id: 

2323 

ShiDvard: 

Jolly  Ship  Building 

Deliverv: 

1/7/77 

Hull  Number: 

232 

DWT: 

40000 

C.1 


General  Arrangement 


C.2 


The  Oil  Tanker 

List  of  Inspections 


Long  Beach  12/1/96 

Description 

Planned  class  society  5  year  survey 

Underway  12/1/93 

Description 

Crew  inspection  of  hull 
Personnel 

Bloggs.  Joe 

Report 

Oil  A. 

Long  Beach  12/17/90 

Description 

Repairs  undertaken  after  Inspection 
Repair  coating  in  ballast  tanks 

Long  Beach  12/16/90 

Description 

Bottom  walked  tank 
Class  society  5  year  survey 
Personnel 

Brown,  Matthew 
Bloggs,  Joe 
Smith,  John 
Jones,  Bill 

Report 

USCG 

CS 

Richmond  12/12/86 

Description 

Repaired  Leak  in  longitudinal  Bulkhead 


Inspection  Planned 


Inspection  Completed 


Oil  A. 

ABC-556 

Repairs  Completed 


Inspection  Completed 


Inspector  An  Inspection  Company 

Oil  A. 

Inspector  USCG 

Company  representative  Oil  A. 


ABC-555 

Repairs  Completed 


The  Oil  Tanker  _ _ _ _ _ _ _ 

Summary  of  Failures  Across  Class 

Class  Vessel  Location  Date 

Class  1 

Class  2 

Class  3 

Pittino 

other 

Total 

70KDWT 

The  Oil  Carrier 

2 

Long  Beach 

12/14/93 

1 

1 

2 

The  Oil  Carrier 

1 

1 

13% 

14% 

11% 

The  Oil  Tanker 

3 

Richmond 

12/12/85 

2 

1 

A 

i 

2 

10 

Long  Beach 

12/16/90 

3 

3 

1 

1 

4 

Long  Beach 

12/17/90 

2 

2 

0 

Long  Beach 

12/1/95 

A 

i 

2 

17 

The  Oil  Tanker 

7 

6 

1 

1 

88% 

86% 

100% 

100% 

100% 

89% 

70KDWT 

8 

7 

1 

1 

2 

19 
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The  Oil  Tanker 

Tanks 

M 

Tank  Name 

Tank  Location 

Caoacitv 

Aft  Frame 

Fwd  Frame 

Tank  coating 

Ballast 

33 

3P 

Port 

1 

Epoxy 

35 

3S 

Starboard 

1 

Epoxy 

45 

5P 

Port 

1 

Epoxy 

47 

5S 

Starboard 

1 

Epoxy 

Ballast  Caoacitv: 

4 

Cargo 

28 

1C 

Centre 

1 

OT  Frame  4 

OT  Frame  1 

Inorganic  Zinc 

27 

1P 

Port 

1 

OT  Frame  4 

OT  Frame  1 

Inorganic  Zinc 

29 

IS 

Starboard 

1 

OT  Frame  4 

OT  Frame  1 

Inorganic  Zinc 

31 

2C 

Centre 

1 

Inorganic  Zinc 

■jU 

2P 

Port 

1 

Inorganic  Zinc 

32 

2S 

Starboard 

1 

Inorganic  Zinc 

34 

3C 

Centre 

1 
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43 

A  O 

4C 
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Centre 

1 
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42 

4P 
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1 

Inorganic  Zinc 

44 

4S 
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1 

Inorganic  Zinc 
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5C 
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1 

Epoxy 

Cargo  Caoacitv: 

11 
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Tank  Coating  Repairs 


Tank  Memo 

Bulkhead 

From  Frame 

To  Frame 

IP 

Long  Beach 
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Long  Beach 
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IS 
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1 P  Aft  Transverse  Bulkhead 

OT  Frame  4 
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The  Oil  Tanker 

Summary  of  Failures  By  Tank 

Vessel  Tank 

Class  1 

Class  2  Class  3  Pittina  Other 

Total 

The  Oil  Tanker 

1C 

2 

1 

2 

IP 

4 

2  111 
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IS 
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A 

2P 

The  Oil  Tanker 
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6  112 
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17 
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Summary  of  Failures  By  Detail  Type 


Vessel  Detail  Tvae 

Class  1  Class  2  Class  3  Pittinfl 

Other  Total 

The  Oil  Tanker 

5  6  1 

in  o 
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1 
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